This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]