[squeak-dev] Debugging of other processes with wait

Jakob Reschke forums.jakob at resfarm.de
Thu Jul 23 12:50:42 UTC 2020


Hello,

Yesterday I needed to debug a process that is not the UI process. At
one point this background process waits on a Promise (so it will wait
on a Semaphore) that is supposed to be resolved in the UI process, so
the background process will block. If this point is reached while
stepping in the debugger, the UI process will block instead, since it
evaluates the debugger stepping on behalf of the background process.

What I did for now is to add an accessor on ProcessScheduler that
answers the activeProcess without sending #effectiveProcess, and check
in Promise>>wait whether this real active process is the UI process.
If it is, halt the debugged process before the Semaphore wait
primitive, and I proceed manually as soon as I am confident that the
promise is already resolved or rejected, so the wait will return
immediately.

wait
    "Wait unconditionally for this promise to become fulfilled or rejected."
    | sema |
    (state = #pending and: [Processor realProcess == Project
uiProcess]) ifTrue: [self halt].
    sema := Semaphore new.
    ...

But of course this is just a workaround. Is there a chance to extend
the Squeak debugger to deal with critical sections and waits? In
Eclipse for example, there is a list of threads; blocked/waiting
threads are annotated with an icon, as well as the top frame that
waits for something; you can debug other threads in the meantime. But
in Java the debugger is in another VM than the debugged process, so
the situation that the debugger steps in the UI process needs not be
resolved there in the first place.

Maybe if we know all the points/primitives where processes can be
blocked, we could make the stepping detect these, run them in another
process, make the debugger observe that process and show some info
about the waiting in a special top context in the meantime. Once the
other process is unblocked (or terminated if it does nothing else than
the wait), the debugger would continue to step the background process.
Could this work?

Or is there already another facility that works and which I should use?

Kind regards,
Jakob


More information about the Squeak-dev mailing list