From owner-freebsd-hackers Sun Jan 18 08:15:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA19223 for hackers-outgoing; Sun, 18 Jan 1998 08:15:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA19156 for ; Sun, 18 Jan 1998 08:14:46 -0800 (PST) (envelope-from grog@lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.8.7/8.8.5) with ESMTP id KAA05272; Sun, 18 Jan 1998 10:14:54 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id KAA11366; Sun, 18 Jan 1998 10:14:53 +1030 (CST) (envelope-from grog) Message-ID: <19980118101453.00324@lemis.com> Date: Sun, 18 Jan 1998 10:14:53 +1030 From: Greg Lehey To: Terry Lambert Cc: hackers@FreeBSD.ORG Subject: Re: Why no sys/setjmp.h? References: <19980117181703.04492@lemis.com> <199801171640.JAA23493@usr07.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <199801171640.JAA23493@usr07.primenet.com>; from Terry Lambert on Sat, Jan 17, 1998 at 04:40:16PM +0000 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk On Sat, Jan 17, 1998 at 04:40:16PM +0000, Terry Lambert wrote: >> 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. What's evil about this thing? > 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 In other words, adapt my algorithm to the subset of functionality which you consider non-evil, at the expense of readability and performance. Yes, of course I considered this alternative. >>>> 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. I think you're assuming that more than one process is involved. I don't know why. > 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. Can you apply this thread to your diagrams above? Greg