IPC Timeouts

[Martin Pohlack]

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

-- 
Martin Pohlack
gpg key:     http://os.inf.tu-dresden.de/~mp26/keys/Martin_Pohlack.asc
fingerprint: 4506 2C3C F5FA 96E6 0EA4 314D A8C2 1C32 1545 8E58