On 3/5/21 6:59 AM, Chris Torek wrote:
On Fri, Mar 05, 2021 at 04:02:16AM -0500, Jeff King wrote:
I don't know offhand if this [bind in a child] trick actually works. ...
On Fri, Mar 5, 2021 at 1:29 AM Jeff King <peff@xxxxxxxx> wrote:
I was curious, but this does indeed work:
[working example snipped]
Yes, it definitely works. The bind() call, on a Unix domain socket,
creates a file system entity linked to the underlying socket instance.
The file descriptors, in whatever processes have them, provide
read/write/send/recv/etc linkage to the underlying socket instance
(and also a refcount or other GC protection: with the ability to
send sockets over sockets, simple refcounts stop working and we
need real GC in the kernel...).
Of course, once all the file descriptor references are gone, the
socket (eventually, depending on GC) evaporates. The file system
entity does not count for keeping the underlying socket alive. At
this point the file system entity is "dead". Unfortunately there's no
way to test and clean out the dead entity atomically. The whole
thing is kind of a mess.
Chris
The original problem was that chdir() is not safe in a multi-threaded
process because one thread calling chdir() will affect any concurrent
file operations (open(), mkdir(), etc.) that use relative paths.
I think Adding a fork() at this layer would just create new types of
problems. For example, if another thread was concurrently writing to
a socket while we were setting up this new socket, we would suddenly
have 1 thread in each process now writing to that socket and the
receiver would get a mixture of output from both processes. Right?
Jeff
