Libguestfs - Jul 2019 - Re: [PATCH libnbd] api: New nbd_kill_command API for sending a signal to the command subprocess.

On Thu, Jul 25, 2019 at 03:19:23PM -0500, Eric Blake
wrote:
> This looks a bit funny until I read the docs at [1].  When using
> kill(2), I'm used to the function call 'kill(pid, 0)' probing
for
> process existence.  But on the command line, kill(1) has the behavior of
> sending SIGTERM by default when you omit a signal number (and not
> serving as a process existence probe).
The reason for this choice is that in some language bindings we might
not have the SIG* symbols available, but there ought to still be a way
to send a default.  Hopefully people will read the docs :-)

I pushed it with s/signal/signum/.

Are we waiting on any other ABI breaks or would now be a good time to
do another 0.x release?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/

On 7/25/19 4:11 PM, Richard W.M. Jones wrote:
> On Thu, Jul 25, 2019 at 03:19:23PM -0500, Eric Blake wrote:
>> This looks a bit funny until I read the docs at [1].  When using
>> kill(2), I'm used to the function call 'kill(pid, 0)'
probing for
>> process existence.  But on the command line, kill(1) has the behavior
of
>> sending SIGTERM by default when you omit a signal number (and not
>> serving as a process existence probe).
> 
> The reason for this choice is that in some language bindings we might
> not have the SIG* symbols available, but there ought to still be a way
> to send a default.  Hopefully people will read the docs :-)
Your explanation is good enough for me :)
> 
> I pushed it with s/signal/signum/.
> 
> Are we waiting on any other ABI breaks or would now be a good time to
> do another 0.x release?
I know we've debated about a flag to nbd_shutdown to give the user more
control over whether to wait on in-flight commands to settle, but
without code for that, I don't see it stalling another 0.x release. In
the meantime, we've definitely broken API/ABI, so another release makes
it easier to test against.  Still, I'd appreciate a few minutes to post
my possible optimization of VALID|FREE in a few more spots, though.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

On Thu, Jul 25, 2019 at 04:23:12PM -0500, Eric Blake
wrote:
> On 7/25/19 4:11 PM, Richard W.M. Jones wrote:
> > On Thu, Jul 25, 2019 at 03:19:23PM -0500, Eric Blake wrote:
> >> This looks a bit funny until I read the docs at [1].  When using
> >> kill(2), I'm used to the function call 'kill(pid, 0)'
probing for
> >> process existence.  But on the command line, kill(1) has the
behavior of
> >> sending SIGTERM by default when you omit a signal number (and not
> >> serving as a process existence probe).
> > 
> > The reason for this choice is that in some language bindings we might
> > not have the SIG* symbols available, but there ought to still be a way
> > to send a default.  Hopefully people will read the docs :-)
> 
> Your explanation is good enough for me :)
> 
> > 
> > I pushed it with s/signal/signum/.
> > 
> > Are we waiting on any other ABI breaks or would now be a good time to
> > do another 0.x release?
> 
> I know we've debated about a flag to nbd_shutdown to give the user more
> control over whether to wait on in-flight commands to settle, but
> without code for that, I don't see it stalling another 0.x release. In
> the meantime, we've definitely broken API/ABI, so another release makes
> it easier to test against.  Still, I'd appreciate a few minutes to post
> my possible optimization of VALID|FREE in a few more spots, though.
Sure that's fine, I'll wait til tomorrow.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html