<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <font face="Georgia">Well, here's a bit more.<br>
      <br>
      2 timesRepeat: [[[1000 factorial &gt; 0] whileTrue] forkAt: 30].<br>
      <br>
      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.<br>
      <br>
      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.<br>
      <br>
      If you remember when this might have run succesfully, then it
      might be possible to look for intervening updates that changed
      something.<br>
      <br>
      Cheers,<br>
      Bob<br>
      <br>
      <br>
    </font>
    <div class="moz-cite-prefix">On 12/5/12 10:40 PM, Chris Muller
      wrote:<br>
    </div>
    <blockquote
cite="mid:CANzdToFFc0j32=y8WUz1PycA0QgDofBiFK8JNpLxmv3Utb4rcw@mail.gmail.com"
      type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">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.
</pre>
        </blockquote>
      </blockquote>
      <pre wrap="">
Sure, that makes perfect sense but...

</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">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.
</pre>
        </blockquote>
      </blockquote>
      <pre wrap="">
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&gt;&gt;#resume simply calls #primitiveResume, it
doesn't add anything to any linked list does it?

</pre>
      <blockquote type="cite">
        <pre wrap="">Yes, it's certainly in the use of the primitive, not the primitive itself.
</pre>
      </blockquote>
      <pre wrap="">
Bert what do you mean by "the use of the primitive"?  It's getting
called (by Process&gt;&gt;#resume) I can't think of any other way to use
it..?

</pre>
      <blockquote type="cite">
        <pre wrap="">Why does the process need to be resumed if it's going to be debugged anyway?
</pre>
      </blockquote>
      <pre wrap="">
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?


</pre>
    </blockquote>
    <br>
  </body>
</html>