IPC Timeouts

[Ronald Aigner]

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? 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.

Greetings,
Ron.
-- 
Ronald Aigner
ra3 at os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/~ra3/