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
