On Thu, Feb 22, 2007 at 04:00:45PM -0500, Greg A. Woods wrote:
> At the most you will probably need to add some calls to yield thread
> execution in key places, though if your application is as well
> understood by your programmers as you tend to suggest it is then that
> should be a relatively easy and perhaps even almost mechanical task
> (though take heed of the warnings in the Pth manual about this!).

If the application is anything like the ones that I work on[1], then
adding yield() calls is essentially impossible.  Not /actually/
impossible, but so difficult, and so deleterious to performance
(both elapsed and real-time, both important) that it is essentially
impossible.  Think of background tasks doing heavy numerical lifting
with heavily optimized matrix arithmetic libraries: you're *not*
going to sprinkle yield() calls through an FFT routine and win.

On the other hand, I expect that my code will work quite nicely with
a 1:1 scheduler and kernel threads: I only have a handful of threads
and hardly any interactions between them.

I don't know what Bucky's code is doing, but I just wanted to add a
word of caution to the idea that you can necessarily avoid
preemption.

[I haven't yet explored more esoteric alternatives, like sharing
memory between separate processes: the heavy-lifting task in one
process, and the more event-driven threads using a user-level
mechanism in another.  Could work, but could also have other
gotchas.]

[1]: these don't use NetBSD, yet, but I've been a NetBSD user
for many years (since 0.9), and I'd like to see my projects move
that way, eventually.  So I take a keen interest in this sort of
discussion.  Hope you don't mind me interjecting.

Cheers,

-- 
Andrew