search for: set_next_state_and_block

...gt; + *next_state = %SEND_WRITE_PAYLOAD; > else > - SET_NEXT_STATE(%SEND_REQUEST); > + *next_state = %SEND_REQUEST; It would be nice to do this without fiddling with essentially an internal detail of the generated code. Could we add another macro, something like "SET_NEXT_STATE_AND_BLOCK"? On the other hand if it's not on the hot path, maybe we shouldn't do this at all? Rich. > return 0; > } > > -- > 2.20.1 > > _______________________________________________ > Libguestfs mailing list > Libguestfs@redhat.com > https://www.redh...

...PAYLOAD; >> else >> - SET_NEXT_STATE(%SEND_REQUEST); >> + *next_state = %SEND_REQUEST; > > It would be nice to do this without fiddling with essentially an > internal detail of the generated code. > > Could we add another macro, something like "SET_NEXT_STATE_AND_BLOCK"? Yes, that's a nice idea, and easy enough to squash in. > > On the other hand if it's not on the hot path, maybe we shouldn't > do this at all? It wasn't on the hot path on any test I could come up with (where we were waiting for the server anyway); but it may sti...

nbdkit 1.2 as a server waits for read() to see EOF, even after the client has sent NBD_CMD_DISC. That was fixed in mbdkit 1.4; and most modern NBD servers are smarter than this (they close() the write end of their traffic soon after NBD_CMD_DISC). But it's easy enough to revert nbdkit commit c70616f8 to get back to a server with the same behavior as the older nbdkit, at which point both

...- * call SET_NEXT_STATE before returning then the state machine - * blocks and will not be re-entered until an external event - * happens (see below). + * runs. If the C code calls SET_NEXT_STATE and returns 0 then + * the connection enters the next state without blocking. If the + * C code calls SET_NEXT_STATE_AND_BLOCK and returns 0 then the + * connection blocks, but will resume with the code for the next + * state on the next external event. If the C code does _not_ + * call either macro but returns 0, the state machine is blocked + * and will not be re-entered until an external event happens + * (see below),...

When processing a server reply within the REPLY subgroup, we will often hit a situation where recv() requires us to block until the next NotifyRead. But since NotifyRead is the only permitted external action while in this group, we are effectively blocking CmdIssue and NotifyWrite events from happening until the server finishes the in-progress reply, even though those events have no strict

I still need to wire in the use of *_notify functions into nbdkit to prove whether it makes the code any faster or easier to maintain, but at least the added example shows one good use case for the new API. Eric Blake (6): api: Add nbd_aio_in_flight generator: Allow DEAD state actions to run generator: Allow Int64 in callbacks states: Prepare for aio notify callback api: Add new