On Mon, 10 Apr 2000 17:31:35 EDT, Dan Sugalski wrote:
>The only sane way to handle signals with threads is to mask them off for
>all your threads except one that's set up to handle them.
That's just one half of the problem. We still need a first-class event
abstraction. Can anyone kindly summa
According to Chaim Frenkel:
>
> Why should a signal mask per_THREAD, be any harder than a signal mask
> per_PROCESS?
>
Because POSIX threads are _supposed_ to be implementable on top of a
UNIX system that doesn't have kernel threads. And that means that a
robust implementation has do do a
Somewhat tangential but still related:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-04/msg00418.html
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
> "CS" == Chip Salzenberg <[EMAIL PROTECTED]> writes:
CS> I agree. POSIX threads' signal-handling model is really awkward, if I
CS> understand it correctly. I've never spent a lot of time on it, but
CS> wearing my implementor hat, just the very idea of having a separate
CS> signal mask for
At 02:25 PM 4/10/00 -0700, Chip Salzenberg wrote:
>According to Joshua Pritikin:
> > o the POSIX standard is technically stupid. It's much better to use a
> > cleaner fundamental threading model and build on top of that.
> > o things like the above are just so much better and more easily d
At 05:06 PM 4/10/00 -0400, Joshua N Pritikin wrote:
> o the POSIX standard is technically stupid. It's much better to use a
> cleaner fundamental threading model and build on top of that.
It's a technical compromise and isn't perfect. This is supposed to be a
surprise? There's not a cross-
According to Joshua Pritikin:
> o the POSIX standard is technically stupid. It's much better to use a
> cleaner fundamental threading model and build on top of that.
> o things like the above are just so much better and more easily done in
> user space anyway.
I agree. POSIX threads
