search for: flush_on_update

...el api design, something very similar to that. An example flow for a read request would be as follows: 1) nbdkit reads and validates the request from the socket 2) nbdkit calls handle_request but now also passing in the nbd request handle value 3) nbdkit bundles the nbd request handle value, bool flush_on_update, and read size into an opaque ptr to struct 4) nbdkit calls my_plugin.pread passing in the usual args + the opaque ptr 5) my_plugin.pread makes an asynchronous read call with a handler set on completion to call nbdkit_reply_read(conn, opaque ptr, buf) or on error nbdkit_reply_error(conn, opaque_ptr...

...t; to that. > > An example flow for a read request would be as follows: > > 1) nbdkit reads and validates the request from the socket > 2) nbdkit calls handle_request but now also passing in the nbd request > handle value > 3) nbdkit bundles the nbd request handle value, bool flush_on_update, and > read size into an opaque ptr to struct > 4) nbdkit calls my_plugin.pread passing in the usual args + the opaque ptr We can't change the existing API, so this would have to be exposed through new plugin entry point(s). > 5) my_plugin.pread makes an asynchronous read call with a...

...n example flow for a read request would be as follows: > > > > 1) nbdkit reads and validates the request from the socket > > 2) nbdkit calls handle_request but now also passing in the nbd request > > handle value > > 3) nbdkit bundles the nbd request handle value, bool flush_on_update, and > > read size into an opaque ptr to struct > > 4) nbdkit calls my_plugin.pread passing in the usual args + the opaque > ptr > > We can't change the existing API, so this would have to be exposed > through new plugin entry point(s). > > > 5) my_plugin.pread...