K42 OS

[Bill Huey (hui)]

On Sat, Nov 22, 2003 at 09:08:58AM -0500, Michal Ostrowski wrote:
> > > Underneath all of this, I think there are interesting issues arising
> > > from interactions between thread management and IPC.  
. ..
> (This is not my particular area of expertise, I'm just referring to some
> issues off the top of my head.  I can certainly refer you to someone who
> is our real expert in this area with specific questions.)

I'm just curious about what you were talking about in that above statement.
What issues about thread management and IPC and I'm not sure if this was
covered by a paper on the topic. A pointer to a paper would be nice, haven't
gotten to the ones you posted earlier just yet. :)

[Linux emulator]
> This is explained in our Freenix paper.
. ..
> application (and the dynamic linker/loader if appropriate)  and lets
> them run.   We reflect system-call traps back to exec.so (or a
> k42-specific glibc will make calls into the system call handlers
> directly).

I'll read that paper.

> Our current approach to pthreads is to rely on Linux libraries; we
> recognize the appropriate clone() calls and create new threads in
> response to those.  The rest of exec.so must then be careful to present
> linux-threads compatible viewsof the world (e.g. threads appear to be
> processes).   We don't have the corner cases, our implementation is good
> enough for now, and not complete (we implement things "on-demand").
> 
> We need to revisit this space in the near future as we look at the new
> Linux pthreads model.
> 
> It's important to understand in this space what one wants to support. 
> Supporting pthreads is one thing, supporting linuxthreads (i.e. the
> linux-specific assumptions about thread properties and behavior) is
> quite another.  I believe we should support pthreads and not
> linuxthreads.

Yes, I was wondering about the new Linux threading interfaces since
LinuxThreads is rather crappy. They should be able to do a Posix compliant
threading system now with their recent futex work, which should all for
Sun's JVM to run without overly complicated threading logic. Their OS glue
layer is disturbingly complicated, but can be reduced in complexity greatly
if you have a mostlly compliant Posix threads system with exposed thread
internals. It needs solid corner case free thread suspension and access to
the ucontext of a thread for GC collection, all of which is rather
complicated in Solaris threads, [un]bounded/invalid thread contexts, etc...

It's something that'll have to eventually be explored when folks start
implementing the UTS for DragonFly, particularly in relation to a JVM port.

Posix threading is definitely the way to go if you can get away with it.

bill