pthread_create() blocks if maxthreads reached?

[Daniel Eischen]

On Sat, 31 Jan 2004, Julian Elischer wrote:
> 
> On Sun, 1 Feb 2004, Craig Rodrigues wrote:
> >
  [ ... ]
> > 
> > If I link this program with -lthr or -lc_r, the
> > program will terminate.
> 
> Successfully? 
> that's interesting.. libthr should theoretically b elimited to about
> 8000 threads.. (on x86).
> 
> > 
> > If I link with -lpthread, the program seems to
> > block in the pthread_create() call, instead of
> > returning EAGAIN (to indicate that a new thread cannot
> > be created due to hitting some system limit). 
> 
> is that what you expected?

The threads are created and scheduled in userland (the default
is process scope threads, so there is no syscall needed to
create these threads).  You probably even created more than
`sysctl kern.threads.max_threads_per_proc` but when the
main thread got swapped out (due to quantum expiration)
and the other threads were scheduled, they blocked in
the kernel and _then_ the system resource limit was hit.
There were no threads left for upcalls, and even if there
was one left for an upcall, there's no guarantee that the
library can figure out which thread to resume so that
your application gets an appropriate error return.

> > 
> > Any ideas on this?
> 
> yes
> to stop processes running away and making the system unusable while we
> are developing the therad package we made a limit on how many 
> threads we allow to ente the kernel at one time per process..
> If you trust your program, you could over-ride the limit.
> 
> see:
> kern.threads.max_threads_per_proc: 150
> kern.threads.max_groups_per_proc: 50
> 
> Your threads are all waiting in the kernel.
> If you used a blocked semaphore or some other non-kernel
> method of blocking then you would discover that you could do more
> or you could allow more threads to enter the kernel at a time
> but that would be a poor use of resources.. it is much more
> efficient to keep blocked threads in userland than to block them in the
> kernel where they use precious kernel resources.
> I'm not sure but I think 'sleep()' is intecepted for example to 
> keep the sleeping threads in userland. (I may be wrong.
> I don't know if Dan did that yet).

Yes, we did :)

> BTW the limit is not on making more threads, its that the last select()
> REALLY blocked and did not return to the userland program to allow you
> to make a new  thread.

Right, what Julian said :)

-- 
Dan Eischen