Date: Sun, 18 Jan 1998 07:12:56 +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: <199801180712.AAA08255@usr04.primenet.com> In-Reply-To: <19980118101453.00324@lemis.com> from "Greg Lehey" at Jan 18, 98 10:14:53 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Because you are doing this evil thing, you need to unwind your stack > > state. > > What's evil about this thing? "you need to unwind your stack state". [ ... ] > 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. Some of us think setjmp/longjmp reduce readability. You shouldn't need to reduce performance, and you should not need to rewrite your algorithm significantly. If you have something you are going to need three functions down, you make sure that it's there before you start on your way three functions down. Theis effective.y unrolls the graph without significantly changing the code. There is one additional question, for each scarcity, that you ask up front. The answer determines whether you start your three calls down in the first place. You ask this question the same place you would ask the question about the return value of setjmp(). The setjmp/longjmp approach is like shooting at targets without knowing that the target is in the right place until you don't hit it, then turning back time so the bullet is back in the gun. You *will* take a performance hit each time you longjmp: you will take the hit of having to do everything you did to get three functions down all over again next time. [ ... ] > I think you're assuming that more than one process is involved. I > don't know why. I don't know why you think I am assuming that. You have an intention to do something that you don't know if you can do or not until after it's too late. It became too late when you decided to do the test three functions down, instead of in the top function. All intention mode locing does is, effectively, virtually move all of the tests you will need to pass or longjmp about, up front, to the top of the call graph. For example, if you needed an mbuf, and the reason you were longjmp'ing was you tried to allocate one NOWAIT, and the allocation failed because it would have blocked, then the correct thing to do is to allocate the buffer at the top to be potentially used later. This would mean that your driver would check to see if it was allocated, and if it had been used previously, then it would allocate another one; if the allocation failed, then you would be where you would have been with your longjmp. Only you never had to call setjmp/longjmp to get there. Your allocation would occur one ahead of your use. A side effect would be that your driver would always have an MBUF on hand almost all the time (except when it was used before you reentered the top where it would be allocated again). Effectively, you have intention mode locked an mbuf. You *intend* to use it, but you are *not* using it yet. > >> Which situation? > > > > The situation where you needed to throw an exception. > > Can you apply this thread to your diagrams above? I think I just did... ;-). 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?199801180712.AAA08255>