cvs commit: src/lib/libthread_xu Makefile pthread.map src/lib/libthread_xu/arch Makefile.inc src/lib/libthread_xu/arch/alpha Makefile.inc src/lib/libthread_xu/arch/alpha/alpha pthread_md.c src/lib/libthread_xu/arch/alpha/include pthread_md.h src/lib/libthread_xu/arch/amd64 ...

[Matthew Dillon]

:On Thu, Feb 03, 2005 at 07:31:51AM +0800, David Xu wrote:
:> Linux has exit_group() which I think is used to implement exit().
:> FreeBSD introduced thr_exit and kse_exit to exit single thread,
:> and leave orignal exit() to exit whole process.
:
:I haven't looked up the semantic of exit_group, but exit() must
:terminate the whole program.  If we want to fully support POSIX
:signal sematic, we have introduce another exit mechanism to cancel
:a part of a thread group.
:
:Concerning the cleanup of code, waitpid (or waittid) seems to be
:enough for my reading of the SUS. It should not be a problem to
:defer the resource freeing until pthread_detach or pthread_join
:is called. If I read the requirements correctly, one or the other
:has to be called by the program anyway.
:
:Joerg

    All right, you guys have convinced me we need an exit_group()
    type of deal.  The linux exit_group() call takes a single
    status argument.  It is unclear what the linux exit() call does.

    This is what I recommend, based on the discussion.  We make our
    legacy exit() system call call terminate all threads (what we do
    with the libc exit/_exit is another matter).

    We add exit_group() with the following semantics:

    exit_group(how, status, addr)

    where how can be:

    EXIT_GROUP_THREAD	Terminate the current thread (rfork/RF_CLONE) and
			store the status value at the specified user address.

    EXIT_GROUP_ALL	Terminate the entire program and return the status
			value as the exit code.  If addr is non-NULL, the
			status value is also stored at the specified user
			address.

    This gives us some room to grow to add additional features such as 
    signal notification or whatever without having to add more system calls.

    I'm not going to be able to work on such a call for a week at least,
    would someone else like to have a go at it?  David, would you like to
    try your hand at system call writing ?

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>