NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/lang/smalltal/2323

Text File | 1992-11-18 | 5.4 KB | 121 lines

Newsgroups: comp.lang.smalltalk
Path: sparky!uunet!gatech!news.byu.edu!hamblin.math.byu.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!ticipa!ticipa.pac.sc.ti.com!tomb
From: [e-mail] (Thomas Burns)
Subject: Re: Restarting contexts in V/286
In-Reply-To: [e-mail]'s message of Tue, 17 Nov 1992 22: 25:29 GMT
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News System)
Organization: Texas Instruments Manufacturing Technology Center
References: <[e-mail]>
Date: Wed, 18 Nov 1992 18:44:46 GMT
Lines: 108

In article <[e-mail]> [e-mail] (Bob Hinkle) writes:

   Newsgroups: comp.lang.smalltalk
   Path: ticipa!tilde.csc.ti.com!csc.ti.com!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!cs.uiuc.edu!sparc0b!hinkle
   From: [e-mail] (Bob Hinkle)
   Sender: [e-mail]
   Organization: University of Illinois at Urbana-Champaign
   Date: Tue, 17 Nov 1992 22:25:29 GMT
   Lines: 41

Well Bob, you've stumbled into a hornet's nest.  Luckily, there are
ways out without getting too badly stung.  I too have written an
exception handler for V/286, and mine is about 98% compatible with that
found in St80.  Now, to your questions...

      I'm almost done implementing an exception handler for V/286,
   but I'm still having one problem:  I can't seem to restart
   the current process at a different context using the
   Process>>restartAt: method.  I *can* restart one (suspended)
   process from another, much like what the Debugger does, but I also
   want to be able to restart the current one.  The solution I came
   up with, and the one Digitalk's technical support suggested, is:

   restart: aContext
       | index process |
       "Restart the #handle:do: context."

       process := Process copyStack.
       index := process indexOfContext: aContext.
       process restartAt: index

   Process>>copyStack is supposed to create a copy of the CurrentProcess,

This is the first place you went awry.  There is much confusion
surrounding copyStack, and it took me a series of about 6 phone calls
to an expert to get it all straightened out.  The copyStack does NOT
copy the process.  What it does do is copy the stack of the currently
executing process (regardless of what's in the CurrentProcess global)
from the internal machine stack INTO the stack of the Smalltalk
process pointed to by the CurrentProcess global.  As an aside, a
simple way to create a snapshot of a running process is to turn all
interrupts off (VERY important), save CurrentProcess somewhere, set
CurrentProcess to Process new, do 'Process copyStack', save the newly
created process in your favorite storage location, restore
CurrentProcess to its previous value, then reenable interrupts.

   so we should be able to manipulate it without messing things up.

Along with what I mentioned above, manipulating the stack of the
process returned from #copyStack is like a doctor performing open
heart surgery on himself.  If a task switch should occur before you
are done, watch out, anything can happen.  From walkbacks complaining
of indexes out of range to toasting your image entirely.

   Process>>indexOfContext: is a method we added that returns the
   frame index of a given context, and it works correctly based on
   independent tests.  But the result of running this method is
   always an error in which the process' index into its indexed instance
   variable is negative.  Checking things out, I added the following

Ah.  Just what I mentioned above.

   test:

   restart: aContext
       | index process |
       "Restart the #handle:do: context."

       process := Process copyStack.
       process == CurrentProcess ifTrue: [self halt].
       index := process indexOfContext: aContext.
       process restartAt: index.

   When this method is run, the halt in the block is activated, which
   tells me that while Process>>copyStack has some side effects, it's
   still returning the current process, rather than the non-active
   identical copy of the current process that I think I need.  Does
   anyone out there have insights into this problem?

                       Bob Hinkle

Another side effect of copyStack is that it is allowed to return
twice.  The first time it returns it answers a pointer to the
CurrentProcess.  If no task switch has occurred, you can do a
'CurrentProcess resume' and the copyStack method will return a second
time and the return value will be the Process class.  Nifty, huh!  For
an example, take a look at ProcessScheduler>>#fork:at:.  This method
contains everything mentioned earlier.  It uses copyStack to create a
new process, checks its return value to see if it is the first or
second return from the #copyStack method, etc.

I don't know how deep you want to get into V exception handling, but
it took me about 4 months to come up with a reasonably bug free
version that was nearly compatible with St80.  We have code that must
run under both V and 80, so an exception handler was imperitive.  I
have considered trying to get the code out into the public domain as I
am sure many would find it useful, I just haven't addressed doing that
yet.

If you have more questions, feel free to ask.

tom

--
Tom Burns                       Domain:    [e-mail]
Texas Instruments               TI MSG:    THOS
P.O. Box 655012, M/S 463        Voice:     [phone]
Dallas, TX   75265              FAX:       [phone]