On Thu, 1 Dec 2005 23:09:43 +0000
Emmanuel Dreyfus <manu@netbsd.org> wrote:

> On Thu, Dec 01, 2005 at 11:49:24PM +0100, Hubert Feyrer wrote:
> > On Thu, 1 Dec 2005, Emmanuel Dreyfus wrote:
> > >Please find attached a proposal for emulating Linux exit_group(). I'm not
> > >sur it follows The Right Way.
> > 
> > There's probably a stupid idea in this question, but still:
> > Did you talk to some Linux people about this, or
> > look at Linux sources to see how/what they do?
> 
> They use their own threading system :-)
> 
> The problem is mapping Linux thread semantics on NetBSD kernel objects: 
> threads or processes. We chose to use processes with shared memory.

NPTL still uses clone(2) and a 1:1 model from what I read about it
(although I admitedly didn't look at the code yet), but indeed some
kernel functionality was added to allow more POSIX consistency, for
instance futex(2) to ease conditional waiting and also some other
functionality so that threads get IDs but all share the same process ID,
i.e. signals can be sent to the process as a whole now.  They can
finally free SIGUSR1 and SIGUSR2 in the implementation :))

Would cloning such added functionality using NetBSD LWPs be feasible?
They still use processes, but those processes seem to now be able to
share more than previously, including for instance process credentials
(our LWPs pretty much also share the same things, if I recall?)

As for your current idea solution for exit_group() I couldn't come up
myself with a more reasonable solution that wouldn't need loads of
changes in the kernel, unfortunately.

Just to maybe keep inspiration going, since these are supposed to only
be threads, there is no process/lwp cleanup hooks that it could execute
in linux prior to exiting?  If not, a system such as SIGKILL (as
previously thought) indeed seems like a close solution, except that
some hacking is still needed around the parent's SIGCHLD reporting...

Perhaps that a similar but "hidden" signal with special handling might
potentially work?  Considering that it forcefully causes waiting and
non-waiting processes to exit, it seems less prone to problems related
to explicitely using wakeup(9), perhaps (some blocking syscalls don't
expect to be interrupted and have no provision for EINTR/restart or
such)...

Or would using LWPs simply allow to _lwp_exit(9) them?

Matt

-- 
Note: Please only reply on the list, other mail is blocked by default.
Private messages from your address can be allowed by first asking.