btw it's very common on unix to share FDs in multi-threaded programs. and all the pain resulting from un-synchronised FD access is available as expected :)
On 10/4/23, hiro <23h...@gmail.com> wrote: > file descriptors describe to the kernel which of the files you > previously open()'ed (a syscall) you want to operator on. > > it's not about security: if you want to operate on a file that another > process might have opened before, you have to be careful that the > other process isn't writing to the same location in the file at the > same time. the kernel also keeps offsets for you. > > if you share FDs between multiple processes you might want some > synchronisation like locking. > > On 10/4/23, Chris McGee <newton...@gmail.com> wrote: >> Hi All, >> >> I was thinking about file descriptors in the context of Plan 9. On Unix >> an >> fd is generally only usable by the current process, and child ones >> through >> a fork with some special incantation if one wants to communicate one over >> a >> domain socket. This is possibly for security reasons, avoiding other >> users' >> processes from trying to guess the fd of a critical file. >> >> It's common practice in Plan 9 to post an fd (sometimes via a pipe) from >> one process to the /srv filesystem so that others can discover it and >> open >> a comms channel. Does the kernel transform the fd into something when >> posted to /srv so that it can be consumed by any other process in the >> system? >> >> Thanks, >> Chris ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tfaa2554a9b74c479-Mcf0b3c1629feb1b852c3224d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
