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

[Pete French]

> 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?

I was thinking of a situations where someone compiled some code and
links it against their favourite thread library and synchronize stops working
silently, because its calling locking and waiting primitives in some other
thread library.

> 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...

Thats what will happen I suspect. But it's probably worth adding a caution in
the documentation somewhere that the runtime will only support synchronise
between threads created with the pthread library. If a platform has more
than one basic thread library available, then theres scope for trouble.

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

Ahhh, shame... I've got some great little bits of syntax in my head to
build OCCAM style parallelism stuff into Obj-C :-)

-bat.