This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: Merge objc-improvements-branch to mainline
- From: kaih at khms dot westfalen dot de (Kai Henningsen)
- To: gcc-patches at gcc dot gnu dot org
- Cc: discuss-gnustep at gnu dot org
- Date: 02 Oct 2003 00:15:00 +0200
- Subject: Re: PATCH: Merge objc-improvements-branch to mainline
- Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
- Organization: Organisation? Me?! Are you kidding?
- References: <E1A2JGu-000He0-00@toybox.twisted.org.uk> <D5BE8F20-EEF0-11D7-9E98-00039390FFE2@apple.com>
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