Andreas, Anthony

Comparing the croquet scheduling issues to a typical
real-time system the information about scheduling a
process is delegated to the scheduler and a process table.
In smalltalk the process table would be integrated into
the process so I would expect a CroquetProcess to be a
subclass of Process and contain the various parameters
needed to determine its deadline.  Having a CroquetProcess
would also allow you to specialize #terminate to insure
the correct action occurs.  You could also have a
#debuggerClass method that returns the proper debugger
class.  However, I think it is better to place the
specialization in the process rather than in the debugger.
You never know what other debugger like things some tool
may want to do in the future.

As far as having a debugger variable in the process is
concerned, VW has an environment ivar which is a dictionary.
When a process is debugged a #debugger variable is added
to the dictionary.  When the process is continued by
the debugger the variable should be removed(I just noticed
that is is not removed, a bug).

Terry

===========================================================
Terry Raymond       Smalltalk Professional Debug Package
Crafted Smalltalk   *Breakpoints* and *Watchpoints* for
80 Lazywood Ln.                  VW and ENVY/Developer
Tiverton, RI  02878
(401) 624-4517      traymond at craftedsmalltalk.com
http://www.craftedsmalltalk.com
===========================================================


> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org]On Behalf Of
> Andreas Raab
> Sent: Tuesday, September 02, 2003 8:02 PM
> To: traymond at craftedsmalltalk.com;
> squeak-dev at lists.squeakfoundation.org; 'Anthony Hannan'
> Subject: RE: Debugger woes
>
>
> Hi Terry,
>
> > I don't have a version of Squeak as I am just a lurker.
> > However, I think I can help considering I wrote the latest
> > version of the VW PDP debugger.
>
> Thanks, it's great to have a third opinion on these issues.
>
> > Andreas's concern about the croquet real-time scheduler
> > is an additional wrinkle.  But, from an Squeak perspective
> > it would be better if the debugger did not have to
> > address special croquet concerns.
>
> I agree but that was essentially the reason why I wanted to be able
to
> handle most of the debugging activities "outside" of the process
being
> simulated so that (for example) a CroquetProcess might use a
> CroquetDebugger
> instead of a "normal" one. This is why I said it would be
> nice to have an
> association between the debugged process and its debugger so
> the process can
> simply pass requests on to the debugger "just in case" some
> special action
> needs to happen. In the default case these actions may do
> nothing so it
> would be simple to substitute debuggers for varying needs.
>
> > In vw I would solve
> > using a normal exception handler.  When a process is
> > terminated in VW, a terminate exception is raised.
>
> This isn't currently the case in Squeak.
>
> > A croquet process could catch this exception and not allow
> > it to continue if the process was being debugged.  The
> > handler could optionally extend the deadline or place it
> > into a special state so the scheduler.  To make this
> > consistent the process would also have to be notified
> > when it was resumed by the debugger.  This could be
> > done by adding a #resumeByDebugger method to Process
> > that raises an exception when resumed by the debugger.
> > This would allow the process to properly change its
> > deadline.
>
> Right. If you follow down this path (which is certainly
> doable) you end up
> with essentially the same mechanisms that I was describing -
> just bundled up
> in one place (class Process) and using tons of not-too-nice ways of
> interactions along context chains (what happens if there is a
> catch-all
> handler somewhere on the stack? Just recently David used one
> ;) So what I'm
> really arguing for here is a better separation of concerns and a
> teenie-weenie bit of explicit knowledge within class Process
> about whether
> it may be debugged or not.
>
> Also, note that the situation of process termination is a
> minor aspect for
> Croquet. Termination semantics are well enough defined and
> the standard
> semantics of Squeak processes work just fine for it. It's the actual
> debugging activity, all the sends involved where we may have
> to deal with
> the fact that the current process is being debugged and may
> therefore have
> "slightly different" rules.
>
> Cheers,
>   - Andreas
>
>
>