Re: [patch] threading enhancements, tid-2.5.47-C0

[Jamie Lokier <lk@tantalophile.demon.co.uk>]

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