On Thu, 15 Aug 2002, Jamie Lokier wrote:
> > On Tue, 13 Aug 2002, Ingo Molnar wrote:
> > > we dont really want any signal overhead, and we also dont want any extra
> > > context-switching to the 'master thread'. And there's no master thread
> > > anymore either.
> >
> > That still doesn't make it any les crap: because any thread that exits
> > without calling the "magic exit-flag interface" will then silently be
> > lost, with no information left around anywhere.
i'm not quite sure why you repeated this part. I replied to this point,
read it.
> also:
>
> > If the parent wants to get notified on child death, it should damn well
> > get notified on child death. Not "in case the child exists politely".
and this point got replied to as well.
> Ingo, the reason I suggest a futex, and to store the exit status in it,
> is precisely because of the above by Linus... [...]
which was incorrect, and replied to. Please re-read the thread. There's no
'silent loss' of anything, and there is no 'unpolite exit'.
> [...] if a thread exits without calling "magic exit-flag interface" I
> would still like a parent thread to know about it. (This is for
> _non-glibc-threads_ applications). [...]
precisely what makes you think glibc does not want to know about about
child thead exit?
> [...] And I would like this while having the benefit of CLONE_DETACHED -
> because I want to use this for high performance threading but still be
> robust - so waitpid() is out.
like i said in the original email, the point of CLONE_DETACHED is to avoid
the waitpid() overhead. I also said that exit notification is done via
mutexes (futexes).
> So - following Linus' note on CLONE_CLRTID - store the tid when the
> thread is created, store the exit status when the thread is destroyed,
> and after storing the exit status, call sys_futex(address, FUTEX_WAKE,
> 1, 0) if the word value before storing was non-zero. The condition is
> to avoid the slowness of sys_futex when it's not required. It's
> probably most simple to use two consecutive words, for simplicity and to
> avoid needing an atomic store (which is slower on some architectures).
no, this is completely unnecessery. We already release the child-exit
mutes before calling the exit, that is a perfectly fine solution. No need
to add extra code to the kernel.
> This gives synchronous (FUTEX_WAIT), asynchronous (FUTEX_FD) and polling
> (just read memory) interfaces to a parent monitoring its child (or
> siblings monitoring each other). It gives access to the same
> information as waitpid(), but with the advantages of CLONE_DETACHED.
>
> All this for these few untested lines in the exit path :-)
this is a horrible hack that is completely unnecessery:
> if (tsk->user_vm_lock) {
> long user_word;
> if (likely(!get_user(user_word, tsk->user_vm_lock))) {
> put_user(tsk->exit_code, tsk->user_vm_lock);
> wmb();
> if (user_word < 0)
> sys_futex (tsk->user_vm_lock, FUTEX_WAKE, -user_word, 0);
> }
> }
the futex wake is being done before the exit, and it works just fine:
16265 clone(child_stack=0x567ffee0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|0x790000) = 16355
16355 _exit(0) = ?
16265 clone(child_stack=0x56fffee0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|0x790000) = 16356
16265 futex(0x56ffff38, FUTEX_WAIT, -1, NULL <unfinished ...>
16356 futex(0x56ffff38, FUTEX_WAKE, 1, NULL) = 1
16265 <... futex resumed> ) = 0
you are banging on open doors.
Ingo
-
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 : Thu Aug 15 2002 - 22:00:40 EST