[lkml]   [1996]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: mutex syscall patch, questions about clone and its possible bugs

> I'm implementing a POSIX threads package using clone()
> for the system threads. It is working fine for me. Follows
> is a sample for creating a system thread although I'm not
> claiming it doesn't have problems. I hope we can hold off
> on the kernel pthread patches because it seems that there
> are several parties working on system threads. I would like
> to provide a real hybrid user/system thread engine rather
> than use MIT threads that are shipping with libc, but that
> isn't up to me so... :)

I remember when at one time Chris Provenzano said something about
people wanting one thousand threads in one application. The kernel
can't cope with that number of threads very nicely, he proposes to use
a number of kernel threads (ie, our clone() created threads) and then
keep a pool of his userlevel threads to do the work.

This is from Theo de Raadt (, commenting on a
question I had:

> > I have
> > the impression that pthreads may assume just one kernel thread, is
> > this the case?
> the free pthreads code is userland only. There's 3 ways to do threads.
> 1) single process, using setjmp() and timers and wrappers for read()
> and such.
> 2) rfork() each thread, and write mutex code. this has the obvious
> problem that processes are too heavy weight. Solution? DUAL-level
> scheduling.
> 3) solaris way. You have a bag of kernel threads, and whenever a
> system call happens you merrily squirrel away into a different
> kernel thread. When you return you have code to get you back to
> the right userland thread. I think David can describe this better.
> 3 is nicest, but has some nasty problems when adapted to a kernel.
> 2 is easy, but there's no dual-scheduling code at all.
> 1 is what we have today, and might be possibly changeable into 2.

Best wishes,

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