Messages in this thread | | | Date | Wed, 20 Nov 2002 21:55:40 +0000 | From | Jamie Lokier <> | Subject | Re: [patch] threading enhancements, tid-2.5.47-C0 |
| |
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/
| |