<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <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>
    Well, I don't know where they keep the VM source these days, but
    when it was included in the image it looked like this:<br>
    <br>
    <b>primitiveResume</b><br>
    <br>
        | proc |<br>
        proc _ self stackTop.  "rcvr"<br>
        "self success: ((self fetchClassOf: proc) = (self splObj:
    ClassProcess))."<br>
        successFlag ifTrue: [ self resume: proc ].<br>
    <br>
    <b>resume: aProcess</b><b><br>
    </b><br>
        | activeProc activePriority newPriority |<br>
        self inline: false.<br>
        activeProc _ self fetchPointer: ActiveProcessIndex<br>
                             ofObject: self schedulerPointer.<br>
        activePriority _ self quickFetchInteger: PriorityIndex ofObject:
    activeProc.<br>
        newPriority   _ self quickFetchInteger: PriorityIndex ofObject:
    aProcess.<br>
        newPriority &gt; activePriority ifTrue: [<br>
            self putToSleep: activeProc.<br>
            self transferTo: aProcess.<br>
        ] ifFalse: [<br>
            self putToSleep: aProcess.<br>
        ].<br>
    <b><br>
    </b><b>putToSleep: aProcess</b><br>
        "Save the given process on the scheduler process list for its
    priority."<br>
    <br>
        | priority processLists processList |<br>
        priority _ self quickFetchInteger: PriorityIndex ofObject:
    aProcess.<br>
        processLists _ self fetchPointer: ProcessListsIndex ofObject:
    self schedulerPointer.<br>
        processList _ self fetchPointer: priority - 1 ofObject:
    processLists.<br>
        self addLastLink: aProcess toList: processList.<br>
    <br>
    <b>addLastLink: proc toList: aList</b><br>
        "Add the given process to the given linked list and set the
    backpointer<br>
        of process to its new list."<br>
    <br>
        | lastLink |<br>
        (self isEmptyList: aList) ifTrue: [<br>
            self storePointer: FirstLinkIndex ofObject: aList withValue:
    proc.<br>
        ] ifFalse: [<br>
            lastLink _ self fetchPointer: LastLinkIndex ofObject: aList.<br>
            self storePointer: NextLinkIndex ofObject: lastLink
    withValue: proc.<br>
        ].<br>
        self storePointer: LastLinkIndex ofObject: aList withValue:
    proc.<br>
        self storePointer: MyListIndex   ofObject:  proc withValue:
    aList.<br>
    <br>
    So, either the process you are resuming or the lower-priority active
    process will be added to its proper priority list. If that process
    is already on the list, then your situation could arise.<br>
    <br>
    <blockquote
cite="mid:CANzdToFFc0j32=y8WUz1PycA0QgDofBiFK8JNpLxmv3Utb4rcw@mail.gmail.com"
      type="cite">
      <pre wrap="">

</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>
    First question: was there anything in Suspended{rocesses when you
    encountered the error? Was it the process you were resuming?<br>
    <br>
    Second: can you describe how to recreate the problem?<br>
    <br>
    Cheers,<br>
    Bob<br>
    <br>
    <blockquote
cite="mid:CANzdToFFc0j32=y8WUz1PycA0QgDofBiFK8JNpLxmv3Utb4rcw@mail.gmail.com"
      type="cite">
      <pre wrap="">
</pre>
    </blockquote>
    <br>
  </body>
</html>