discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kai Henningsen
Subject: Re: PATCH: Merge objc-improvements-branch to mainline
Date: 02 Oct 2003 00:15:00 +0200

zlaski@apple.com (Ziemowit Laski)  wrote on 24.09.03 in 
<D5BE8F20-EEF0-11D7-9E98-00039390FFE2@apple.com>:

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

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

Well, there *is* detachNewThreadSelector:toTarget:withObject: and all the  
rest of NSThread ...

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

... and libobjc already *has* a thread abstraction layer. Which mostly  
works on Win32, too. (And GNUstep *does* use that layer to implement  
NSThread.)

Given that there is a lock abstraction in libobjc, I see no reason why gcc  
can't simply use that to implement @synchronized.

The trick here seems to be that the latter appears to work with any old  
object, so any old object has a lock ... surely not? That seems like too  
much overhead.

MfG Kai




reply via email to

[Prev in Thread] Current Thread [Next in Thread]