Yikes! I think you should report that as a bug in Squeak. The comment in Process>>primitiveResume says:<br><br>"Primitive. Allow the process that the receiver represents to continue. Put <br> the receiver in line to become the activeProcess. Fail if the receiver is <br>
already waiting in a queue (in a Semaphore or ProcessScheduler). "<br><br>Seems like something is wrong with the primitive.<br><br>I'm not sure how I ended up with that #resume in there in the first place. Probably the test was failing and in an instant of confusion I thought I was missing a resume and then it ended up passing so I never noticed. Looking at it again, the code was not just "not portable"; it was completely non-sensical.<br>
<br>Julian<br><br><div class="gmail_quote">On Sat, Feb 7, 2009 at 12:52 AM, James Foster <span dir="ltr"><<a href="mailto:Smalltalk@jgfoster.net">Smalltalk@jgfoster.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I think I know what is happening here...<br>
<br>
In VW and Dolphin, sending #'resume' to a process waiting on a semaphore gives an error (you can only resume a suspended process, not a waiting one).<br>
<br>
In GemStone, sending #'resume' to a process waiting on a semaphore is silently ignored.<br>
<br>
In Squeak, sending #'resume' to a process waiting on a semaphore lets the process become active (terminating the wait) even though the semaphore was not signaled! I think that this is the least desirable of the possible outcomes.<br>
<br>
I'll update the test with something more portable.<br>
<br>
James<br>
<br>
Following is my sample code:<br>
<br>
| sem1 proc1 sem2 proc2 sem3 value |<br>
sem1 := Semaphore new.<br>
sem2 := Semaphore new.<br>
sem3 := Semaphore new.<br>
proc1 := [<br>
sem1 signal.<br>
sem1 wait.<br>
"the process will resume if sem1 is signaled or (on Squeak) anyone sends #resume to proc1!"<br>
sem3 signal.<br>
value := 1.<br>
] newProcess.<br>
proc2 := [<br>
sem3 wait.<br>
sem2 signal.<br>
] newProcess.<br>
proc1 resume.<br>
proc2 resume.<br>
sem1 wait.<br>
proc1 resume. "this puts proc1 on the run queue even though sem1 is not signaled!"<br>
sem2 wait.<br>
value.<div><div></div><div class="Wj3C7c"><br>
<br>
<br>
On Feb 6, 2009, at 2:39 PM, James Foster wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Julian,<br>
<br>
I got a failure on this test in GemStone because of a deadlock (no processes are available to run). I've added lots of debugging code to the test, but the upshot is that I think it was missing a signal for semaphore1 (the test previously had two waits and only one signal). I'm not sure how it could run on Squeak, but with the extra signal it runs the same way on both Squeak and GemStone.<br>
<br>
Could you review and comment?<br>
<br>
James<br>
_______________________________________________<br>
seaside-dev mailing list<br>
<a href="mailto:seaside-dev@lists.squeakfoundation.org" target="_blank">seaside-dev@lists.squeakfoundation.org</a><br>
<a href="http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev" target="_blank">http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev</a><br>
<br>
</blockquote>
<br>
_______________________________________________<br>
seaside-dev mailing list<br>
<a href="mailto:seaside-dev@lists.squeakfoundation.org" target="_blank">seaside-dev@lists.squeakfoundation.org</a><br>
<a href="http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev" target="_blank">http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev</a><br>
</div></div></blockquote></div><br>