Commenting out the #resumeProcess: send in #debugProcess: makes this work.

I'm for removing the the whole suspension logic. If you want to suspend the process, why not just debug it, and then proceed when you're done?

- Bert -

On 2012-12-06, at 19:28, Bob Arning <arning315 at comcast.net> wrote:

> Well, here's a bit more.
> 
> 2 timesRepeat: [[[1000 factorial > 0] whileTrue] forkAt: 30].
> 
> Now try to debug one of these in the ProcessBrowser - byebye squeak. The problem is in the PB trying to resume a process that's already on the list for its priority in Processor.
> 
> A similar problem I noted yesterday is that trying to debug a higher-than-UI priority process that was waiting on a semaphore fails as PB signals the semaphore and resumes the process. But the signal lets this process run (to completion, maybe), so nothing left to debug.
> 
> If you remember when this might have run succesfully, then it might be possible to look for intervening updates that changed something.
> 
> Cheers,
> Bob
> 
> 
> On 12/5/12 10:40 PM, Chris Muller wrote:
>>>> 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?
>> 
>> 
>> 
> 
>