[squeak-dev] Confusing #timeoutSemaphore:afterMSecs: method on the class side of Delay

Hi all.

I was showing Gary Chambers today how Albatross (the Seaside  
functional testing framework) would hang when tests within it failed.  
This is in a (I think!) web-dev image, based on 3.10. The hang was an  
unsignalled Semaphore.

It turned out to be because the class-side method  
#timeoutSemaphore:afterMSecs: message on the class side of Delay looks  
like this (I have omitted the lengthy comment):

timeoutSemaphore: aSemaphore afterMSecs: anInteger
        ^ (self forMilliseconds: anInteger) schedule

Clearly from this, if you use (as Albatross does, together with a  
number of other classes) Semaphore>>#waitTimeoutMSecs:, which in turn  
sends #timeoutSemaphore:afterMSecs: the semaphore which sends itself  
to Delay never gets signalled!

I checked that this version was what it should be, according to the  
3.10 MC repository (http://source.squeakfoundation.org/310), and it's  
the same version as is in there.

We tried this simple alternative (comment again omitted):

timeoutSemaphore: aSemaphore afterMSecs: anInteger
        ^ (self new setDelay: anInteger forSemaphore: aSemaphore) schedule

Since #forMilliseconds: on Delay sends to #setDelay:forSemaphore: on  
Delay anyway.

Hey-presto. No image crash/lock (always a good sign for changes on  
Semaphore, Delay et al!), and Albatross now acts as expected.

So, is this change crazy? It seems so simple and obvious that its  
almost sure to be wrong just by that fact :)

Cheers,
Simon




******************************************************************************************************************************************
This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. *******************************************************************************************************************************************


Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

Simon Kirk wrote:
> So, is this change crazy? It seems so simple and obvious that its almost
> sure to be wrong just by that fact :)

This got broken in 3.9. Your version is obviously correct.

Cheers,
   - Andreas

After talking with Ken Causey on IRC, looks like our fix is pretty much like
the 3.8 implementation. I wonder what went on to introduce the problem
anew... lack of senders until 3.10 (the 3.10 use of the method is correct,
just the change in the meantime is wrong, I believe).

Regards, Gary.