search for: next_ready_to_serve

...d user but before it accepts a connection. This > is very late and the only real use for this is for a plugin to create > background threads for its own use. > --- > +++ b/docs/nbdkit-filter.pod > > +=head2 C<.ready_to_serve> > + > + int (*ready_to_serve) (nbdkit_next_ready_to_serve *next, void *nxdata); > + > +This intercepts the plugin C<.ready_to_serve> method. > + > +If there is an error, C<.ready_to_serve> should call C<nbdkit_error> > +with an error message and return C<-1>. Do we need to require the filter to be involved in the re...

...ameter because it cannot be @@ -284,6 +285,15 @@ filter doesn't slow down other filters or plugins. If there is an error, C<.thread_model> should call C<nbdkit_error> with an error message and return C<-1>. +=head2 C<.ready_to_serve> + + int (*ready_to_serve) (nbdkit_next_ready_to_serve *next, void *nxdata); + +This intercepts the plugin C<.ready_to_serve> method. + +If there is an error, C<.ready_to_serve> should call C<nbdkit_error> +with an error message and return C<-1>. + =head2 C<.open> void * (*open) (nbdkit_next_open *next, void *nxdata,...

This is my second attempt at this. The first version (also not working) was here: https://www.redhat.com/archives/libguestfs/2019-October/msg00062.html In part 1/2 I introduce a new .ready_to_serve plugin method which is called after forking and just before accepting any client connection. The idea would be that plugins could start background threads here. However this doesn't work well in