|
|
Hi,
I look into a way to implement something like Erlang's selective process by having Delay
or something like it wait on multiple Semaphores (and maybe blocks in the future but that
leads the question of side-effects if the event is not used) and fire on the first one ready
without having to deal with many Processes.
The usecases I have in mind right now are:
* Wait for a delivery time or if any new work has come up
* When connecting a call (e.g. two SIP calls) I want to manage the state from a
central place (e.g. like an event inbox) and dispatch events from the same context
and I do not know which side the event occurs.
SelectiveReceive new
check: database readableSemaphore do: [ev := self nextDatabaseEvent];
check: file readableSemaphore do: [];
timeoutDo: [];
runFor: 30 seconds.
A prototype to get a feel for the API could be built by spawning n-processes that each
wait on their own semaphore for the timeout and then create another semaphore that
is signalled by these processes in case of a wakeup signal the new Semaphore and then
in the runFor: selector kill all remaining processes..
What do you think of this pattern instead of having to deal with concurrency with more
locking, more fine grained locking? What would it take to get this deeper into Pharo? I
think fundamentally a Process would need to be able to sleep on a list of semaphores?
Is that feasible?
kind regards
holger
|
Locked
