Am Mittwoch, den 29.07.2009, 21:23 -0500 schrieb Stef Bidi: > David C.: > I took a quick look at your comments and did some quick > modifications... uploaded the results. There were a few things that > will need a lot more work, so I left those as is for now. > > David A.: > I am using threads and locks, and unfortunately it's the only way for > me to get where I want to be (streaming audio data). If I understood > your replies correctly, your suggesting using pthread instead of > NSLock and NSConditionLock? David C. expressed some concerns on how > I'm using the locks as well.
Yes, well, almost... I am suggesting that you use the objc_thread threading abstraction layer in libobjc instead of NSThread. David C. is suggesting to use pthread directly and avoid the abstraction layer. I believe that David C. believes that all deployments we care about have a pthread library they /could/ use. I believe he believes both your code and GNUstep proper should simply use that independent of what the objc_runtime and the gcc runtime uses. I'm not sure whether he believes that gcc already uses pthreads under the abstraction layers for $(ALL_RELEVANT_PLATFORMS) or not. From his last reply I would infer that he may believe that we simply shouldn't have to care. He does believe, that by using pthreads directly we can make use of some optimizations / avoid inefficiencies that the abstraction layers introduce. I believe we do have to care. GNUstep currently doesn't define which platforms it supports. We simply do not know. I do know that the discussions on the mailing list is not an indication of what is in use. I also believe that the approach to bypass NSThread by using the abstraction layers is fairly common practice. Most use cases I know have a very limited interaction with the rest of the system and are often performance critical. They are written in plain C, so no messages are being passed, no notifications processed, just plain grunt work in C. This is also what Apple seems to be doing. Another scenario where threading implementations can be added to the executable are language bridges. Java, Ruby, Python... I'm not sure how JIGS/RIGS work but I have seen bridges that start a VM in a separate thread of the same process. The only way to keep the executable sane and debugable in my view is if all components share the "native" threading environment. The only way I see to make this possible is to use the abstraction layers. Of course I'd also like to see the optimizations that David C. is aiming at. I just don't believe the way to achieve it is by bypassing the abstraction layers. My approach would be to optimize the abstraction layers. But in the end all discussion is moot if no one writes patches. David C. seems to have sent patches. I definitely do not have the time to implement the approach I suggest, so I'll back away from the discussion, save clarifications wrt misunderstandings/misrepresentations. Cheers, David -- David Ayers Fellow of the Free Software Foundation Europe http://www.fsfe.org http://fellowship.fsfe.org _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev