fibril_timer semantics are flawed

[Jiri Svoboda]

Fibril timer does not hold the timer lock while the callback is executed. That means there is no guarantee after return from fibril_timer_clear() that the callback has been either cancelled or has run to completion. It could happen that the callback is still running after we return from fibril_timer_clear(). That makes the return value of fibril_timer_clear() worthless.

fibril_timer is currently used for TCP retransmissions.

[Jiri Svoboda]

The difficult part is that we still want to be able to set the timer again, either from the timer callback function, or from outside of it. So, as an example, just holding the timer mutex while the callback is running would lead to a deadlock, since fibril_timer_set() needs to grab the mutex aswell. One possible solution would be to have a fibril_timer_set_unlocked(), but that would be really really ugly.

[Jiri Svoboda]

For an extra challenge, TCP may attempt to destroy a timer inside its handler function. That means fibril_timer_destroy() must not wait for the timer fibril to terminate.

[Jiri Svoboda]

Fixed in mainline,2136. It is still possible to set the timer from the timer handler function.