[Seaside-dev] WAMutexTest>>#'testExclusion'

[Julian Fitzell]

Yikes! I think you should report that as a bug in Squeak. The comment in
Process>>primitiveResume says:

"Primitive. Allow the process that the receiver represents to continue. Put
    the receiver in line to become the activeProcess. Fail if the receiver
is
    already waiting in a queue (in a Semaphore or ProcessScheduler). "

Seems like something is wrong with the primitive.

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.

Julian

On Sat, Feb 7, 2009 at 12:52 AM, James Foster <Smalltalk at jgfoster.net>wrote:

> I think I know what is happening here...
>
> 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).
>
> In GemStone, sending #'resume' to a process waiting on a semaphore is
> silently ignored.
>
> 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.
>
> I'll update the test with something more portable.
>
> James
>
> Following is my sample code:
>
> | sem1 proc1 sem2 proc2 sem3 value |
> sem1 := Semaphore new.
> sem2 := Semaphore new.
> sem3 := Semaphore new.
> proc1 := [
>        sem1 signal.
>        sem1 wait.
>        "the process will resume if sem1 is signaled or (on Squeak) anyone
> sends #resume to proc1!"
>        sem3 signal.
>        value := 1.
> ] newProcess.
> proc2 := [
>        sem3 wait.
>        sem2 signal.
> ] newProcess.
> proc1 resume.
> proc2 resume.
> sem1 wait.
> proc1 resume.   "this puts proc1 on the run queue even though sem1 is not
> signaled!"
> sem2 wait.
> value.
>
>
>
> On Feb 6, 2009, at 2:39 PM, James Foster wrote:
>
>  Julian,
>>
>> 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.
>>
>> Could you review and comment?
>>
>> James
>> _______________________________________________
>> seaside-dev mailing list
>> seaside-dev at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>
>>
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20090207/16b6fdfc/attachment.htm