From owner-freebsd-arch Tue Jan 22 12: 0:35 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id E2C2C37B404; Tue, 22 Jan 2002 12:00:27 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020122200027.XKFL3578.rwcrmhc52.attbi.com@InterJet.elischer.org>; Tue, 22 Jan 2002 20:00:27 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA18268; Tue, 22 Jan 2002 11:54:21 -0800 (PST) Date: Tue, 22 Jan 2002 11:54:19 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Cc: dillon@freebsd.org Subject: STOP and SLEEP in the kernel Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matt Dillon and I spent some time looking at the way in which process suspension is achieved in FreeBSD in order to try work out how best to do it in the KSE kernel. We discovered a couple of things. FIrstly that teh suspension occurs in CURSIG() which is an alias for issignal() and that CURSIG is called in a number of places, at least one of which seems to us to be a rather dubious place to suspend a process. for example: in cv_switch_catch() cv_wait_sig() msleep() userret() <-this is ok ncp_poll() It seems to us that we need to think carefully about whether suspending a thread in cvwait or msleep is a good idea. ncp_poll() seems a really odd place for a thread to suspend. The difficult part for me in a multithreaded system another thread could call exit() while the thread is stopped there and I need to be able to break it out safely. This means that I need to be able to get it to back out to the user boundary at least, so that I can be sure it's released all resources before I shoot it. Surely a thread can continue within the kernel while the process is stopped as long as it's suspended before it tries to go back to userland. I would suggest that we use a separate check for suspended state, rather than combine it into CURSIG. It would allow a check for signals that would be independent of the worry that the thread would freeze there. PLUS there is in the KSE kernel, now the possibility that a process is suspended in a way completely independent of signals. (this was always the case to some extent as signals really needn't be used for stopping a process for tracing reasons). Signals and suspension are the last major hurdle before I can get a multithreaded process running. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message