Re: NSSound Code Review

[David Ayers]

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