From owner-freebsd-threads@FreeBSD.ORG Sun Feb 1 10:42:22 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5674216A4CE for ; Sun, 1 Feb 2004 10:42:22 -0800 (PST) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15D2C43D41 for ; Sun, 1 Feb 2004 10:42:09 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc13) with ESMTP id <200402011842070150080kste>; Sun, 1 Feb 2004 18:42:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA57215; Sun, 1 Feb 2004 10:42:06 -0800 (PST) Date: Sun, 1 Feb 2004 10:42:04 -0800 (PST) From: Julian Elischer To: Petri Helenius In-Reply-To: <401D2EBD.2030609@he.iki.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE cc: freebsd-threads@freebsd.org Subject: Re: pthread_create() blocks if maxthreads reached? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2004 18:42:22 -0000 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.