As part of adding timer operations to aio_poll and a clock to AioContext, I am trying to figure out a couple of points on how aio_poll works. This primarily revolves around the flag busy.
Firstly, at the end of aio_poll, it has assert(progress || busy); This assert in fact checks nothing, because before the poll (20 lines or so higher), it has if (!busy) { return progress; } and as 'busy' is not altered, busy must be true at the assert. Is this in fact meant to be checking that we have made progress if aio_poll is called blocking? IE assert(progress || !blocking) ? Secondly, the tests I am writing for the timer fail because g_poll is not called, because busy is false. This is because I haven't got an fd set up. But in the instance where aio_poll is called with blocking=true and there are no fd's to wait on, surely aio_poll should either hang indefinitely or (perhaps better) assert, rather than return immediately which is a recipe for an unexpected busywait? If I have timers, it should be running those timers rather than returning. Thirdly, I don't quite understand how/why busy is being set. It seems to be set if the flush callback returns non-zero. That would imply (I think) the fd handler has something to write. But what if it is just interested in any data to read that is available (and never writes)? If this is the only fd aio_poll has, it would appear it never polls. When adapting this for timers, I think it should be returning true only if a an AIO dispatch did something, or a BH was executed, or a timer ran. Specifically if the poll simply times out, it should not be returning true unless a timer ran. Correct? -- Alex Bligh