On 09/19/2012 01:19 PM, Paolo Bonzini wrote: > Il 19/09/2012 12:06, Avi Kivity ha scritto: >>> > (The hunch is that ts could be deleted exactly at the moment the >>> > callback is unlocked. This can be solved with ref/unref on the opaque >>> > value, as you mention below). >> Are you saying that this works as is or not? It does seem broken wrt >> deletion; after qemu_del_timer() completes the caller expects the >> callback not to be called. > > Ouch, then I think the only solution is to remove this invariant if you > add fine-grained locking and re-check the enable conditions in the timer > callback.
I think so too, I know authors of GUI frameworks suffer from this problem (the GUI calling into the framework vs. the framework asking the GUI to repaint). Don't know what the state of the art solution is. > > If you allow calling del_timer to be called with the device lock held, > you cannot fixing without deadlocking. If you don't, the caller of > del_timer cannot set any expectation because the timer could be run in > the window between dropping the device lock and calling del_timer > Right. Callbacks should check qemu_timer_deleted() after taking their little lock. The reference held by the timer subsystem protects against qemu_free_timer(). -- error compiling committee.c: too many arguments to function
