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/