[squeak-dev] Re: Cannot debug from Process browser
Bert Freudenberg
bert at freudenbergs.de
Thu Dec 6 18:44:48 UTC 2012
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?
>>
>>
>>
>
>
More information about the Squeak-dev
mailing list
|