pthread_create() blocks if maxthreads reached?

[David Xu]

Daniel Eischen wrote:

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

You guys are better to not bet that Scheduler Activation can run large 
number of
threads, essential differences with libc_r is libpthread is kernel 
thread based, and
I don't think support of large number of threads is the design goal of 
SA,  it relies
on kernel. libpthread should query the sysctl to see if a new thread 
should be created,
and the sysctl value should be raised only. The benifit of libpthread is 
that it still can save
some resources and implement some POSIX semantics, for example, saving a 
kernel
thread resource if the thread sleeps in userland,  fast context switch ? 
and POSIX
SCHED_RR, SCHED_FIFO, Priority based scheduling...