>>47
Are you saying that Erlang processes are stackless and not affected by priority scheduling?
Anyway, trapping timeouts when send-work-wait is wrapped around asynchronous messaging just means that the receiver hasn't _replied_ soon enough. Isn't the message queued either at the sender or the receiver, at the mechanism level, until the receiver actually gets it? Even in the case of timeout (i.e. the sender giving up before getting a reply), the sent message will hang around in some queue or another, and so might the reply which was given up on if the receiver hasn't died.
>>48
Real-time requirements are surprisingly common outside prototype code. Well, soft real-time anyway, the kind where it's vastly preferable to have a responsive system than an efficient or even simple system.