On Fri, 2 Dec 2005 16:49:41 +0000
Emmanuel Dreyfus <manu@netbsd.org> wrote:

> On Fri, Dec 02, 2005 at 08:06:50AM -0800, Chuck Silvers wrote:
> > > The problem is mapping Linux thread semantics on NetBSD kernel objects: 
> > > threads or processes. We chose to use processes with shared memory.
> > 
> > is this really better than using one process with multiple LWPs?
> > what problems would be caused by switching to that model?
> 
> You mean appart from having a lot of code to change in compat_linux?
> I don't really know, I did not made the decision in the first place.
> 
> Perhaps we use processes because we emulated Linux threads before we had lwp?

Indeed...  Another reason might have been that __clone(2) actually
created processes, not necessarily LWPs (although if it's called with a
special flag to create thread-friendly processes under Linux 2.6, it
would probably be possible to use either a process or LWP, conditionally
on the flag bit being set, but we shouldn't break applications which are
really expecting processes and are non-portably using clone(2) instead
of fork(2))

Of course since I'm not the one maintaining our linux binary
compatibility layer (I have no idea of the amount of code that would
have to be rewritten), and that I didn't check the Linux 2.6 clone(2)
code yet nor the NPTL library code, these are only ideas.

In a week or so from now I'll need a Linux 2.6 development box for a
threaded project code porting attempt (code which didn't work well at
all with LinuxThreads because of its inconsistencies), so I should have
more opportunities to look at how it works (and hopefully I won't speak
behind my hat then (if the french expression maps well to english :))

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