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: Pete French <pete at twisted dot org dot uk>
- To: gcc-patches at gcc dot gnu dot org, kaih at khms dot westfalen dot de
- Cc: discuss-gnustep at gnu dot org
- Date: Thu, 02 Oct 2003 12:09:23 +0100
- Subject: Re: PATCH: Merge objc-improvements-branch to mainline
> Well, there *is* detachNewThreadSelector:toTarget:withObject: and all the
> rest of NSThread ...
NSThread isnt part of the objc language though. You can only use NSThread if
you have an OpenStep implementation around.
> ... and libobjc already *has* a thread abstraction layer. Which mostly
> works on Win32, too. (And GNUstep *does* use that layer to implement
> NSThread.)
I didnt know this at the time, but you are right - and that removes my
concerns, as long as people are aware that they should use the libobjc calls
to do threads.
I still think it would be very nice to have parallelism in the language
itself though - e.g.
@parallel {
[obj1 method1];
[obj2 method1];
[obj3 method1];
}
and have them all execute in parallel, with the block not terminating until
all the individual processes have terminated. From experience this type
of construct makes people write code with a lot more parallelism. Its
top of my "most wanted feature" list anyway - for ObjC, and also C.
Given that theres thread support in libobjc then it becomes even more
appealing - plus it would work very nicely with @synchronise.
-bat.