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
_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Locked
