From owner-freebsd-threads@FreeBSD.ORG Sun Feb 1 08:57:52 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 2402916A4CE for ; Sun, 1 Feb 2004 08:57:52 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8BE043D41 for ; Sun, 1 Feb 2004 08:57:50 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i11Gvkiw006736; Sun, 1 Feb 2004 11:57:46 -0500 (EST) Date: Sun, 1 Feb 2004 11:57:46 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Alex Keahan In-Reply-To: <200402011822.01724.ak@freenet.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Julian Elischer 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:57:52 -0000 On Sun, 1 Feb 2004, Alex Keahan wrote: > On Sunday 01 Feb 2004 5:06 pm, Daniel Eischen wrote: > > > > 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) That isn't true. The main thread can exit and other threads will continue to run and keep the application alive. The threads library can't guess as to which thread is "special". It could be that the main thread creates only one thread, and this thread is the thread that creates all the other threads. The main thread could block in the kernel as well. The threads library can't guess at what your applications really want. You guys are looking at the application and can infer what behavior you'd like to see, but the threads library isn't artifically intelligent. -- Dan Eischen