Thus said Ken Hornstein on Tue, 23 Apr 2019 19:35:11 -0400:
setlock /tmp/mit.lock inc +MyIncTmp ...
Well, my reading of the setlock man page (assuming this is the FreeBSD
one) is that it is not depending on a _descriptor_ to be passed down
(I don't even know how that would work), but in fact it is opening a
particular _file_ and locking it.
Sorry, I should have referenced which setlock I intended. I didn't
realize there was more than one setlock. I specifically had in mind
setlock from daemontools (see http://cr.yp.to/daemontools.html for more
information), though it is not the only command that implements this
interface.
Basically, it opens a file and attempts to obtain an exclusive lock the
file descriptor for that file. If/when it successfully obtains the
exclusive lock it then uses exec() to execute a new process, and that
new process inherits the open file descriptor. As long as that process
leaves the file descriptor open, it continues to hold the lock on said
file which prevents any similarly invoked processes from running
concurrently.
The lock goes away either when the file descriptor is intentionally
closed, or the process exits or crashes.
My change makes it so we no longer close all descriptors when creating
a child process (in the majority of cases we didn't). The particular
change I have started implementing is that any descriptors _created by
nmh_ will be marked as close-on-exec, so they will no longer be available
to child processes (well, technically, child processes that have called
exec(), but you know what I mean).
Yes, I see what you mean---also, I didn't realize that the approach in
nmh was so varied, but then, I haven't looked at the sources in-depth.
This change sounds less drastic than I intially thought. I've run into
problems before (most notably with Bash) where after setlock does exec()
the new process will close inherited open file descriptors which
basically breaks this particular way of resource control (sometimes
referred to as Bernstein chaining).
Thanks for the clarification; it does sound like it will be an
improvement.
Andy
--
TAI64 timestamp: 400000005cbfdd37
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers