Ulrich Drepper wrote:
> Ingo's last patch has two pointer, one for the parent and one for the
> child. The is necessary (despite what Jamie tried to argue) if we want
> to have a cfork() implementation which works in MT applications.
> cfork() is IMO really necessary if you want to mix threads and fork().
Hi Ulrich,
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.
I agree with you, if you need this functionality:
1. cfork(ptr) equivalent to { pid_t p = fork(); if (p > 0) *ptr = p; }
2. The pid is stored in the parent before any signals can be handled.
3. Don't want to block signals temporarily (of course).
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.
> Assume you have an application which forks children and assosicates
> certain actions with the termination of a child. When SIGCHLD is
> received one of the threads of the app searches, using the PID of the
> terminated child, which action has to be performed. It wouldn't find
> anything if the thread, which created the child, hasn't yet written the
> PID of the child in the appropriate memory location. This can very well
> happen and can only be fixed by the kernel writing the PID values.
If the application is using cfork() and requires the pid stored
atomically at _its_ address, which is separate from the thread
libraries current_thread->tid address, then I agree with Ulrich: two
pointers are best.
It's possible to get by with one pointer, but then you're back to
blocking signals in the cfork() implementation, or making the thread
library horrendous in other ways (complicating ->tid reads everywhere).
(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...)
-- 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/
This archive was generated by hypermail 2b29 : Sat Nov 23 2002 - 22:00:30 EST