[Libguestfs] [PATCH libnbd discussion only 4/5] api: Implement concurrent writer.

[Richard W.M. Jones]

On Mon, Jun 03, 2019 at 01:27:47PM -0500, Eric Blake wrote:
> On 6/3/19 10:29 AM, Richard W.M. Jones wrote:
> > +=item 4. Modify main loop
> > +
> > +Finally your main loop can unconditionally call
> > +C<nbd_aio_notify_write> when C<nbd_aio_get_direction> returns C<WRITE>
> > +or C<BOTH> (since the concurrent thread can always enqueue more data
> > +and so is always "ready to write").
> 
> Will we ever actually reach a state that is blocked on a write
> completion for aio_get_direction to ever even request a WRITE or BOTH?
> Or will the state machine always manage to churn through requests in
> their entirety and back to state READY which is just a READ state?

Right, I believe the answer is no, we never get WRITE/BOTH, and that
is also what I observed when closely examining the events in the debug
log earlier today.  However I guess better to be safe.

> > +int
> > +nbd_unlocked_set_concurrent_writer (struct nbd_handle *h,
> > +                                    void *data, writer_cb writer)
> > +{
> > +  /* I suppose we could allow this, but it seems more likely that
> > +   * it's an error rather than intentional.
> > +   */
> > +  if (h->writer != NULL) {
> > +    set_error (EINVAL, "concurrent writer was already set for this handle");
> > +    return -1;
> > +  }
> > +
> > +  h->writer = writer;
> > +  h->writer_data = data;
> > +  return 0;
> > +}
> 
> Is it worth a get_concurrent_writer()?  Not strictly necessary, though.

We could add it later but it raises the question of why anyone would
need it.

> > +  else {
> > +    /* Pass the buffer to the concurrent writer thread. */
> > +    h->writer (h->writer_data, buf, len);
> > +    return len;
> 
> [1] So h->writer is NOT allowed to fail directly (if it fails, it must
> call nbd_concurrent_writer_error instead). Stems from the fact that the
> generator doesn't allow callbacks with a return type, but livable.  But
> may warrant extra wording in the documentation.

Right, it's a limitation of the generator which I should probably fix.
If we had that then we could differentiate "immediate failure" (eg
memory allocation) from later failure of send(2) in the writer thread.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW