Thanks all for the explanations. I think I understand better now.
Chris
> On Oct 4, 2023, at 12:06 PM, o...@eigenstate.org wrote:
>
> Quoth Chris McGee :
>> 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 pr
Quoth Chris McGee :
> 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
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)
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
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 o
