Timeline for Sharing file descriptors
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 16, 2020 at 1:41 | comment | added | benjimin | I'm guessing the linux kernel does actually happen to be in the same reserved address space for every process (regardless that physical addresses are inaccessible), but as you say this is still not the mechanism for sharing file pointers, as the descriptors refer to resources indirectly (via kernel-managed per-process tables). | |
| Mar 9, 2018 at 15:34 | comment | added | Stephen Kitt |
Physical memory addresses aren’t accessible from userspace, so no. Same goes for file descriptors: the full meaning of a file descriptor is only available using information in the kernel, so you can’t transfer one without going through the kernel. To transfer a file descriptor without a socket connection, you can fork...
|
|
| Mar 9, 2018 at 1:41 | comment | added | benjimin | Is there any way to usefully transfer a file descriptor (or a physical memory address) between processes without kernel mediation? Also, is there any way to perform this mediation process without a socket connection? (I'm interested in thread-safe ways to conveniently communicate an anonymous shared mmap to a process pool in python.) | |
| Mar 9, 2018 at 1:37 | vote | accept | benjimin | ||
| Mar 9, 2018 at 1:36 | comment | added | benjimin | Similar explanation here: keithp.com/blogs/fd-passing The infrastructure for different processes possessing shared file descriptors was necessary for POSIX forking; the mystic bit is Linux's intercept-and-translate mechanism for communicating them on other occasions. | |
| Mar 9, 2018 at 1:22 | comment | added | benjimin | Surprising as the sendmsg(2) manual makes no mention of this behaviour (although recvmsg does). | |
| Mar 8, 2018 at 13:49 | history | answered | Stephen Kitt | CC BY-SA 3.0 |