From owner-freebsd-threads@FreeBSD.ORG Sun Feb 1 08:22:57 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 71F2516A4CE for ; Sun, 1 Feb 2004 08:22:57 -0800 (PST) Received: from enigma.barak.net.il (enigma.barak.net.il [212.150.48.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5775D43D1F for ; Sun, 1 Feb 2004 08:22:54 -0800 (PST) (envelope-from ak@freenet.co.uk) Received: from hydralisk ([62.90.149.2]) by enigma.barak.net.il e5bc39f1001e7dfa47fa92d56cd12779) with ESMTP id <20040201162458.YWHV901.enigma@hydralisk>; Sun, 1 Feb 2004 18:24:58 +0200 From: Alex Keahan To: Daniel Eischen , Julian Elischer Date: Sun, 1 Feb 2004 18:22:01 +0200 User-Agent: KMail/1.5.1 References: In-Reply-To: Organization: Home MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200402011822.01724.ak@freenet.co.uk> 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 16:22:57 -0000 On Sunday 01 Feb 2004 5:06 pm, 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. Perhaps the main thread should be treated specially in this regard? It is already special with respect to other threads in that it keeps them on life support (if the main thread exits, the entire process disappears) AK