pthread_create() blocks if maxthreads reached?

[Julian Elischer]

On Sun, 1 Feb 2004, Petri Helenius wrote:

> Craig Rodrigues wrote:
>=20
> >Understood.  Keep in mind, I am trying to "kick the tires"
> >on libpthread, to see how it reacts on crazy corner cases.
> >I can certainly increase the values of these sysctls,
> >but I think that pthread_create() should not block if
> >it hits a limit.
> >
> > =20
> >
> I agree here, pthread_create() should not get blocked sitting somewhere=
=20
> because
> it would easily lead to situations where a "main" thread spawning off=20
> children
> is blocked and cannot report errors or pthread_join() threads that termin=
ate
> because of it=B4s blocked.
>=20




pthread_create() is not blocking..

Pthread_create doesn't result in a system call.
creating new threads si a purely userland activity,
(well, the malloc for the thread may call sbreak, but as you are running
in the thread library that might be a synchronous activity anyhow I
think.. (Dan, does pthread_create() count as an entry into the
thread_scheduler?) In any case if it blocked in sbreak() it would be
awoken very quickly.

To see what is happenning, you have to understand wow these threads
work..

when a thread enters the kernel and blocks, (**) a new kernel thread is
created, made runnable, and set to make an upcal back to the Userland
Thread Scheduler,(UTS) so that a new thread can be scheduled to replace
the one that blocked. The new kernel thread is used for the next
userland thread.. If the limit on kenrel threads is reached, then at the
point marked "**" above, no new thread is created, so no upcall occurs.

basically it's a shell game.. every time a kernel thread blocks, we
create a new one for the process to use instead, until you run out. when
we just don't make one. i.e. the syscall you made still blocks, but no
replacement thread is delivered to teh process to keep running.

The alternative would be to make EWOULDBLOCK a possible error return for
EVERY syscall.. i.e if you did a select(2) as the test program does, and
you recieved an EWOULDBLOCK.. what would you think/do?

Noe that this all applies ONLY to threads blocked in the kernel. you may
have thousands of threads in userland, blocked on userland constructs..
they don't count. Only threads blocked while holding kernel resources.