Il 16/07/2013 18:14, Alex Bligh ha scritto: > Paolo, > >>> 3. aio_poll calls aio_bh_poll. If this returns true, this indicates >>> at least one non-idle bh exists, which causes aio_poll not to >>> block. >> >> No, this indicates that at least one scheduled non-idle bh exist*ed*, >> which causes aio_poll not to block (because some progress has been done). > > Ah yes, in the sense the callback will have been called and it now > doesn't exist.
Or at least isn't scheduled. >>> 4. aio_poll then calls g_poll (POSIX) or WaitForMultipleObjects >>> (Windows). However, the timeout is either 0 or infinite. >>> Both functions take a milliseconds (yuck) timeout, but that >>> is not used. >> >> I agree with the yuck. :) But Linux has the nanoseconds-resolution >> ppoll, too. > > Sadly I don't think we have a g_ppoll. Doesn't matter, poll==g_poll on POSIX systems. You can just use poll (or g_poll) on non-Linux, and ppoll on Linux. >> But I wouldn't introduce a >> new one-off concept (almost as much of a hack as idle BHs), I would >> rather reuse as much code as possible from QEMUTimer/QEMUClock. I must >> admit I don't have a clear idea of how the API would look like. > > So the reason I was trying to avoid using QEMUTimer stuff was that > bh's get called from aio_poll and it was not evident that all timers > would be safe to call from aio_poll. It wouldn't. > What do you think? In the end I thought the schedule_bh_at stuff > was simpler. It is simpler, but I'm not sure it is the right API. Of course, if Kevin and Stefan says it is, I have no problem with that. Paolo
