Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!mcnc!ncsu!fcstools!paul From: paul@fcstools.UUCP (Paul Perkins) Newsgroups: net.micro.mac Subject: Re: Lightspeed C, desk accessories, and BUGS Message-ID: <114@fcstools.UUCP> Date: Sat, 31-May-86 17:23:37 EDT Article-I.D.: fcstools.114 Posted: Sat May 31 17:23:37 1986 Date-Received: Wed, 4-Jun-86 00:34:02 EDT References: <741@jade.BERKELEY.EDU> Organization: Foundation Computer Systems INC., Cary, NC Lines: 28 > LightSpeed C produces buggy desk accessories, and the example desk > accesory is dangerous! > ... > 2) Since the preamble code locks the storage before your code ever gets > called, you can't even save the lock state of the handle and restore it > yourself - the state is already changed before your code ever gets called. The problem is all in your mind, as they say... If you always come into the DA only by the front door (so the autmatic locking is done), you can always unlock the storage when you leave. In DA's where saving and restoring the lock state would have been "necessary and sufficient", it's not hard to keep a variable IN THE DA's STORAGE set to what the previous lock state must have been (assuming it was unlocked when first read in by the resource mangler). This is explained in Lightspeed's own documentation. When you come into the DA, you look at the var, to see if storage was locked, then you make storage locked (if it didn't happen automagically), and set the var to TRUE so any pseudo-reentrant calls will see that it is already, then on the way out you unlock or not, based on the original value of the var, which you kept on the stack of course, and if you unlock you set the var to FALSE. Or something like that. -- Paul Perkins #include Quote: "Some say that Heaven is Hell; some say that Hell is Heaven." -- Kate Bush