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?
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20121206/8dc893b7/attachment.htm