Linus Torvalds wrote:
> So when the child eventually creates a new thread, it needs to know to
> ignore the other thread slots, even though they _look_ valid. They were
> valid in the parent, they aren't valid in the child.
They don't have to be as such. It's a simple list operation (move all
active threads except the active one on the free list). That's it. No
more work especially no resetting of the TID fields.
> I follow your argument, and I don't dislike it per se. I just think that
> you end up having to do other setup for pthreads-after-fork _anyway_, no?
I don't walk the thread descriptors. I don't write into them. I move
entire double-linked lists with a dozen or so instructions. Regardless
of how many threads were active in the parent.
> Basically, I don't see the patch and bits making sense. I see it
> potentially _working_. But that's a different issue - and "working" to me
> is sometimes a much less potent argument than "makes sense".
With the flag and/or two settid pointers available the thread descriptor
for the one thread in the new process is correct and complete from the
first instruction on. The address of the thread descriptor is the same
in parent and child and the only field which needs changing is the tid.
I don't know what else to say. For correct operation the thread
descriptor must be complete and correct and if the kernel doesn't help
setting the descriptor up correctly there always will be a time period
when it is not complete and effectively points to the parent thread in
the old process. If the clone() flag would not be available I would
probably ignore the problem for now but when it becomes a problem the
only way for user-level code to handle the problem is to disable signals
around fork calls in the parent and then re-enable them after fork() and
after setting up the descriptor in the new process. And this still
wouldn't help with debuggers etc.
- --------------. ,-. 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/