Ronald Aigner wrote:
Martin Pohlack said:
Ronald Aigner wrote:
<...>
To imitate the concurrent waiting for an IPC or timer event one could set up a timer with the kernel and inculde the "timer-source" into the receive scope of the wait IPC. Timer events can be dropped if the receiver is not ready. This would also simplify the tasks using IPC timeouts as timer event source.
I see one problem with this:
Scenario:
I use finite timeouts in a library emulating keyboard repeat behaviour (you press the key -> one press event is generated, you keep the key pressed -> after 250 ms another event is generated every 100 ms until you release the key).
This is implemented with IPC-Recv from an event thread with the timeouts mentioned.
Problem:
The setup and start of the timer and the ipc operation in this scenario is atomic. If I would have to setup and start the timer independently of the IPC I could be interupted and/or delayed in-between if no other meassures (e.g. delayed preemption) would be taken.
There could be similar more critical examples (although I think that a spongy keyboard is bad enough).
Wrong assumption: You receive an IPC (key pressed). Then you do some calculation, and decide to wait for the KEY_UP IPC with an timeout (which you have to calculate as 250ms - the time it took you from IPC receive to start of next IPC). And who ensures you that between the calculation of the new timeout you are not interrupted?
I did not say that this solution is currently perfect, but it might be easily fixed by "simple delayed preemption" (aka cli/sti) between the two IPC operations (ca. 10 lines of simple c-code).
You might as well set up the (oneshot) timer in the meanwhile. If it fires and you're not there to get it (because you received the KEY_UP IPC before that), who cares, its dropped.
However, if I have to do another thing between both IPCs (like setting up the timer) more things can go wrong: I would probable have to enter the kernel to setup the timer, which, at least with current Fiasco and "simple delayed preemption" is not possible as the interrupt flags are not preserved across kernel entries.
So, as a consequence, without IPC timeouts we need at least delayed preemption which is robust across kernel entries *and* fast and deterministic timer programing.
I'm not saying these are impossible but the consequences should be considered.
Greets, Martin