Date: Sun, 1 Feb 2004 10:42:04 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Petri Helenius <pete@he.iki.fi> Cc: freebsd-threads@freebsd.org Subject: Re: pthread_create() blocks if maxthreads reached? Message-ID: <Pine.BSF.4.21.0402011025410.38031-100000@InterJet.elischer.org> In-Reply-To: <401D2EBD.2030609@he.iki.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0402011025410.38031-100000>