K42 OS

[Michal Ostrowski]

On Sat, 2003-11-22 at 20:34, Bill Huey wrote:
> 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. :)
> 

The scheduling white paper that I referred to in my original post should
cover this.  


> > 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.
> 

What concerns me is not posix-threads application, but rather
linux-threads applications; application that expect that their threads
map 1-1 to kernel threads and use non-pthreads interfaces (e.g. kill())
to communicate.   For these applications we have to bend over backwards
and kludge things such as getpid() to return some value that we can then
use in kill(), a value that we know refers to some thread within a
process.  




-- 
Michal Ostrowski <mostrows at xxxxxxxxxxxxxx>
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00019.pgp
Type: application/octet-stream
Size: 189 bytes
Desc: "Description: This is a digitally signed message part"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20031123/c6a1f08e/attachment-0020.obj>