Ulrich Drepper wrote:
> > (That said, I'm not entirely convinced that blocking signals in cfork()
> > is so bad, if we assume that cfork() is a relatively expensive
> > operation anyway...)
>
> It could mean a signal cannot be delivered and reacted on in time. The
> other threads could have blocked the signal which arrives. Every time
> signals have to be blocked to implement a function something is wrong,
I don't buy this argument. You block signals, do something, unblock
signals. There may be a _tiny_ delay in delivering the signal - of
the order of a single system call time, i.e. not significant. (That
delay is much shorter than signal delivery time itself). No signals
are actually _lost_, which would be important if it could happen.
Blocking signals briefly is very similar to taking a spinlock. It has
a small overhead, which is probably not significant in the case of
cfork() and its likely applications.
Regarding whether clone() needs a separate child tid_address pointer -
I have no strong opinion (you can implement cfork() with or without),
but you might want to consider, from Glibc's perspective, that there
aren't many argument words left for future uses..
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Nov 23 2002 - 22:00:34 EST