Date: Sun, 18 Jan 1998 10:14:53 +1030 From: Greg Lehey <grog@lemis.com> To: Terry Lambert <tlambert@primenet.com> Cc: hackers@FreeBSD.ORG Subject: Re: Why no sys/setjmp.h? Message-ID: <19980118101453.00324@lemis.com> In-Reply-To: <199801171640.JAA23493@usr07.primenet.com>; from Terry Lambert on Sat, Jan 17, 1998 at 04:40:16PM %2B0000 References: <19980117181703.04492@lemis.com> <199801171640.JAA23493@usr07.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980118101453.00324>