Re: [Qemu-devel] [patch 04/10] qemu: introduce main_loop_break

[Jamie Lokier <jamie@shareable.org>]

Anthony Liguori wrote:
> Marcelo Tosatti wrote:
> >I didnt know. Anthony wrote this code, so I'll let him comment.
> >  
> Is this guaranteed by Posix and reliable across Unixes?  In general, I 
> think it's better to be conservative with this sort of thing.

All the changes I suggested don't depend on pipe atomicity.
(My mistake for bringing it up).

As long as you're only writing 1 byte, write atomicity isn't relevant.
(If the current code actually did anything with its 8 byte
chunks it writes, _that_ would depend on atomicity.)

The trick of reading 2 bytes and assuming the pipe is emptied if you
only get 1 byte doesn't dependent on read atomicity, because in the
unlikely event there is another byte, that's ok: the select() will
return immediately and you'll read again anyway.  That can happen even
with atomicity due to parallelism.  So reading 2 bytes is just a
heuristic trick to avoid an unnecessary system call in most cases.

So here's the signal-safe, thread-safe self-pipe trick as I see it:

   - Set both ends of the pipe to non-blocking.

   - Write 1 byte in signal handler, other threads etc.  Don't care if
     you get EAGAIN; it just means the pipe is full, which is fine.
     (As an optimisation you can set a flag and avoid writing a second
     time when you know the pipe is non-empty.  But to do this right,
     you have to be careful with memory ordering etc.  Maybe this is
     not worth it.)

   - Read 2 or more bytes in the select() handler for the read side.
     If you get all the bytes you asked for, loop doing it again.  The
     loop is to drain the pipe, avoiding spurious select() wakeups.
     When you get fewer bytes than you asked for, the pipe is probably
     empty, but if it isn't that's fine.

-- Jamie