From owner-freebsd-threads@FreeBSD.ORG Sun Feb 1 20:04:39 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 542F916A4CE; Sun, 1 Feb 2004 20:04:39 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6D7A43D3F; Sun, 1 Feb 2004 20:04:37 -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 i1242wiw000380; Sun, 1 Feb 2004 23:02:58 -0500 (EST) Date: Sun, 1 Feb 2004 23:02:58 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: David Xu In-Reply-To: <401DC6C8.6090006@freebsd.org> 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: Mon, 02 Feb 2004 04:04:39 -0000 On Mon, 2 Feb 2004, David Xu wrote: > 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. > > > > You guys are better to not bet that Scheduler Activation can run large > number of > threads, essential differences with libc_r is libpthread is kernel > thread based, and > I don't think support of large number of threads is the design goal of > SA, it relies > on kernel. libpthread should query the sysctl to see if a new thread > should be created, The sysctl only defines how many kernel threads can exist. The library doesn't know how many application threads will end up simulataneously blocked in the kernel. We could limit the number of total threads created to be no more than the sysctl, but that places an artificial limit on the number of threads that may never be reached. If you want to catch EAGAIN or some error on pthread_create(), you can always create your threads with system scope instead of process scope. You should get an error on the pthread_create when you run out of kern.threads.max_groups_per_proc. > and the sysctl value should be raised only. The benifit of libpthread is > that it still can save > some resources and implement some POSIX semantics, for example, saving a > kernel > thread resource if the thread sleeps in userland, fast context switch ? > and POSIX > SCHED_RR, SCHED_FIFO, Priority based scheduling... -- Dan Eischen