[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paolo Bonzini
Subject: Re: [Help-smalltalk] Timeouts for SharedQueue and Semaphore
Date: Wed, 10 Nov 2010 10:00:16 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101027 Fedora/3.1.6-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.6

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]