Re: [Help-smalltalk] Timeouts for SharedQueue and Semaphore

[Paolo Bonzini]

On 11/10/2010 12:51 AM, Holger Hans Peter Freyther wrote:
> would it be possible to add a waitTimeSeconds/MSecs to Semaphore?
> Maybe even to SharedQueue? I would like to write code like the one
> below but I am a bit at a loss of how to realize it without spawning
> many processes.
>
> [ self sendSomeData c := queue nextTimeout: 3. ] on: TimeOut do: [:e
> | ... ]

The right primitive to implement would be "wait for any of these
semaphores".  Then what you need would be easily written as

    nextTimeout: secs
        | delay |
        delay := (Delay forSeconds: secs).
        (Processor activeProcess waitOnAll: {delay. self}) = delay
            ifTrue: [ TimeOut signal ]

Right now the code however is dependent on each process having a single
process, so this is quite complex to do.

So it may indeed make sense to special case waiting on a Semaphore and a
Delay.  The first idea was to do something like this, forcing use of an
external semaphore in Delay:

    Semaphore>>waitTimeout: aDelay
        | sema p |
        sema := Semaphore new.
        p := [self wait. sema signal] fork.
        aDelay waitOn: sema onExternalSignal: [ ^self ].
        p terminate.
        TimeOut signal

... which still needs to fork.  Oh well. :(

However, most of the changes needed for something like 
#waitOn:onExternalSignal: were a nice cleanup anyway so I went ahead 
with them.  After doing this, I checked what Squeak does and the idea is 
to do "process suspend; resume" to take a process out of the semaphore 
wait.  This fits in the new delay code pretty well, even though the 
timed-wait implementation is completely different from Squeak's.  It is 
accessible via Delay>>#timedWaitOn:, patches are welcome to implement 
Squeak's Semaphore-side methods instead.

On top of this, letting the caller know whether there was a timeout from 
#timedWaitOn: requires a small change to the VM.  Luckily, the change is 
in general a good idea.

Paolo