[squeak-dev] Re: Cannot debug from Process browser

Chris Muller asqueaker at gmail.com
Thu Dec 6 03:40:27 UTC 2012


>> Well, it will happen if you add something to a list that's already there. Try this:
>>
>> | list link |
>> list := LinkedList new.
>> link := Link new.
>> list add: link.
>> list add: link.
>> link explore.

Sure, that makes perfect sense but...

>> So if you send #resume to a process with priority less than the active process, it might happen. Or if you try to suspend the active process, but it's already on a suspended list.

One thing I don't understand; I didn't see the connection from your
simple example to what you're saying about resuming a process with
lower-priority.  Process>>#resume simply calls #primitiveResume, it
doesn't add anything to any linked list does it?

> Yes, it's certainly in the use of the primitive, not the primitive itself.

Bert what do you mean by "the use of the primitive"?  It's getting
called (by Process>>#resume) I can't think of any other way to use
it..?

> Why does the process need to be resumed if it's going to be debugged anyway?

In looking at the associated code of ProcessBrowser, there is this
global IdentityDictionary it maintains called 'SuspendedProcesses'.
It is only ever populated by the user selecting "suspend (s)" from the
Process list context menu.  When a process is suspended this way, if
its 'suspendingList' (what is that?) is a Semaphore, then the priority
of the Process being suspended is dropped.  The reason, according to
the comment:

  "Need to take the priority down below the caller's
	so that it can keep control after signaling the Semaphore"

All this, so that, when eventually the user selects "resume (r)" from
the ProcessBrowser list menu, it will be able to restore the original
priority of the maybe-it-was-a-Semaphore Process..??  Whatever!

Does anyone know Is this still needed or just old junk?


More information about the Squeak-dev mailing list