Jamie Lokier wrote:
> This is "int cfork(pid_t * user_tid_ptr)", yes? I've searched google for
> cfork and not found anything fruitful - just references to solaris
> patches about a function of the same name.
It's just a coincident. I made the name up and there is no function
like that so far, at least as far I know.
> Then yes, you need two pointers, one for the parent's cfork() argument
> for SETTID in the parent, and one for the child's thread descriptor
> for CLEARTID in the child. Strictly speaking, SETTID does not need to
> affect the child (because the child can store the tid itself), but it
> would make a lot of sense to do it.
The CHILD_SETTID is needed, too, since otherwise the PID isn't stored in
the child's thread descriptor.
> (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,
- --------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
-----END PGP SIGNATURE-----
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/