lkml.org 
[lkml]   [1996]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: clone() and pthreads?
Date
> On Wed, 1 May 1996, Thomas =?ISO-8859-1?Q?K=F6nig?= wrote:
> >
> > what's clone() doing these days? One guy claimed (via E-Mail) that
> > he'd written a clone()-based pthreads package, but didn't answer
> > when I asked him where I could get it for testing.
> >
> > Does anybody know anything about this? Is clone() stable enough
> > for this kind of thing?
>
> Essentially, development on clone() stopped, because nobody was using it
> and I couldn't get people to even try, and send me reports. I sent out a
> silly test-program (which has shown up a couple times since then) that
> should give technical people a starting point - certainly if somebody
> would know enough to implement pthreads some other way they should have
> no problem understanding that small code-fragment.

I'm actively experimenting with clone() threads on one of my personal
projects. The idea is to code a 3rd generation web server with
dedicated threads accepting/processing requests, sending the requested
objects to the requestor, and executing dynamicly loaded CGI "modules"
which live in the server's space. Thanks to Randy Chapman for helping
me organize my thoughts on it.

The biggest obsticle to doing things with clone() threads is the
complete lack of support. Neither X, libc, db, or anything else is
threadsafe out of the box. You and sct both mentioned ways that
threads can currently upset the kernel -- but so far nothing that a
little locking and common sense can't handle. And there are no
existing locking/syncronization functions -- though alan cox was nice
enough to assult me with a clue stick, and I'm trying to learn GAS's
asm syntax well enough to make an cmpxchg inline so I can make a
decent semaphore. I'm also looking at the mmalloc package that comes
with gdb. GNU mmalloc is certainly not the best malloc around, but it
promises multiple heaps which I hope might be a sort of simple garbage
collection, and I'm curious if having multiple heaps leads to
finer-grain locking for malloc() functions and any sort of win.

The only real "problem" that I've noticed, and maybe its not even a
problem, is that when a thread's parent dies, the thread will continue
happily until it finds its own reason to die. I sorta expected a
dying process to take all its child threads with it.

Christopher


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.103 / U:1.852 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site