Messages in this thread | | | Date | Tue, 19 Nov 2002 20:04:18 -0800 | From | Ulrich Drepper <> | Subject | Re: [patch] threading enhancements, tid-2.5.47-C0 |
| |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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)
iD8DBQE92wnC2ijCOnn/RHQRAqDqAJ9gfHvRN/Lz04EXd04h4VdcNlWjWgCghEjG Cuf+eoUKcJ+9+BcyqpeY/sU= =iW0/ -----END PGP SIGNATURE-----
- 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/
| |