signal-process vs. kill(1)

signal-process vs. kill(1)

[Roland Winkler]

Right now proced.el uses kill(1) to send signals to a process. By
change I discovered the emacs built-in function signal-process that
can send a signal not only to emacs subprocesses but also to any
system process. I am wondering what is the better way to go for
proced.el. It seems to me that using signal-process is the cleaner
way to go. Is that right? Or would it make sense to make this
configurable?

Thanks,

Roland

Re: signal-process vs. kill(1)

[James Cloos]

>>>>> "Roland" == Roland Winkler <Roland.Winkler@physik.uni-erlangen.de> writes:

Roland> Right now proced.el uses kill(1) to send signals to a process. By
Roland> change I discovered the emacs built-in function signal-process ...

Roland> It seems to me that using signal-process is the cleaner
Roland> way to go. Is that right? Or would it make sense to make this
Roland> configurable?

I was about to write that the only difference on posix systems would be
that using (signal-process) will make just one system call (ie kill(2)),
whereas using kill(1) requires calling execve(2), vm allocation,
filesystem reads just so that kill(1) can call kill(2).

But it might be the case in a locked-down system that kill(1) -- or some
similar program -- might have more privs than emacs and therefore may be
able to signal more processes that emacs could directly signal.

Also, I've no idea how process signalling works on doze.

There is no question that (signal-process) should be the default.  But
there might be some corner-case systems where using a separate process
to send signals could be necessary.

On a separate note, users might want to be able to call "sudo kill $foo"
to signal processes they do not own.  If you have or add support for that,
do make "sudo" customizable since there are alternatives in the wild.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6