Date: Sat, 17 Jan 1998 16:40:16 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: grog@lemis.com (Greg Lehey) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG Subject: Re: Why no sys/setjmp.h? Message-ID: <199801171640.JAA23493@usr07.primenet.com> In-Reply-To: <19980117181703.04492@lemis.com> from "Greg Lehey" at Jan 17, 98 06:17:03 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801171640.JAA23493>