Re: PATCH: Merge objc-improvements-branch to mainline

[Ziemowit Laski]

On Wednesday, Sep 24, 2003, at 16:42 US/Pacific, Pete French wrote:

> > It's '@synchronized' (sorry, couldn't resist :-) ), and it currently
>
> Ah well, another one to add to the list of "things to edit before 
> typing
> make the second time" along witn NSColour -> NSColor then :-)
>
> > only works
> > with the NeXT runtime (i.e., on Darwin systems).
>
> ...because you can guarantee what threads library you will be linking 
> against
> preseumably ? On systems with more than one threads library then I 
> guess
> aany implementation in libobjc is going to have to specify what threads
> library it neeeds linking against to work I guess (or at least say 
> that it
> links to a library providing a certain call for thread locking and
> waiting primitves).
>
> Actually that change looks quite nice, though having thread primitives
> in a language which is completely unaware of threads in all other
> ways seeems a bit odd.

How would make the langauge "aware" of threads?  I'm thinking of Java,
where you have 'synchronized' and a "thread library" in the form of
java.lang.Thread, but that seems to be it!  (Please correct me if I'm
wrong.)

Also, I think that the locking and waiting that the @synchronized 
construct
requires can be easily implemented on top of just about any thread 
library,
and I don't see why the semantics of said locking and waiting 
would/could
suffer as a result.  What kind of problems do you foresee?

Also, I suppose that if/when you guys choose to add exception support to
the GNU runtime, you can standardize on, say, pthreads and be done with 
it...

> You wernt tempted to add in a few extra bits of
> syntax to support parallelism in the language itself at all were you ?

Nope. :-)

--Zem
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477