From owner-freebsd-hackers Sat Jan 17 08:40:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA08828 for hackers-outgoing; Sat, 17 Jan 1998 08:40:32 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA08820 for ; Sat, 17 Jan 1998 08:40:25 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id JAA06110; Sat, 17 Jan 1998 09:40:26 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp01.primenet.com, id smtpd006099; Sat Jan 17 09:40:19 1998 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id JAA23493; Sat, 17 Jan 1998 09:40:16 -0700 (MST) From: Terry Lambert Message-Id: <199801171640.JAA23493@usr07.primenet.com> Subject: Re: Why no sys/setjmp.h? To: grog@lemis.com (Greg Lehey) Date: Sat, 17 Jan 1998 16:40:16 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: <19980117181703.04492@lemis.com> from "Greg Lehey" at Jan 17, 98 06:17:03 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk > As Mike Smith pointed out, 'function' is a poor choice of words. I'm > in the top half of a driver (in process context *only*), checking > configuration information, which requires a number of nested function > calls. It does not require communication with the bottom half of the > driver. OK, you have an acyclic directed graph, any you are starting at the end and traversing state in one direction on the edge: | v o \ <- can unwind this state transition via 'return' o \ <- have to unwind this state transition via 'longjmp' o Because you are doing this evil thing, you need to unwind your stack state. You need to reorder your function call graph so that there is only a depth of one so you can unwind state using a return value from the function: | v o / \ <- can unwind both these state transitions via 'return' o o > >> Could you explain how to use tsleep()/wakeup() to perform this > >> function? > > > > Obtain intention mode locks before descending. > > Locks on what? Descending where? This is pure code. With the > exception of having to read disk blocks at times, there is no > interruption. Reading the disk blocks is not part of the problem, > though it would cause the process to be scheduled. Locks on the state you intend to change. If you require that every state you will change must be possible to change to the new state before you attempt the first state-change, then you will never encounter an exception. An exception occurs when an action you are attempting fails. If you use locks to ensure it can never fail, then you don't have to deal with it failing. If you never *encounter* an exception, you will never need to *handle* an exception. > > If you have a possible conflict, then the intention mode lock wasn't > > granted, and this situtation never arose. 8-). > > Which situation? The situation where you needed to throw an exception. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.