You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Parent and child processes overwrite each others output, when using shared files. This is happening due to lack of a shared file offset across processes. In traditional UNIX systems and probably also in Linux systems, the file structure is as follows:
file descriptors in process fd table -> kernel level open file table -> vnode/inode. and file offsets are stored in kernel level open file table.
Cases:
when independent processes open the same file.
In this case each process will have a fd in its own process table, which will be pointing to an entry in kernel open file table. so even kernel open file table will have two entries each from corresponding processes pointing to the same inode/vnode. so in this case file offsets are completely independent as they are two different entries in open file table. and overwriting is normal behaviour.
when forking happens and child and parent process write to the same file.
Assuming Atomic writes each process will have its own entry of fd in its process table, which points to the same entry in kernel open file table. so both fds point to the same entry in the open file table. Thus sharing the file offset and each of them update this as and when writes happen.
Why this behaviour?
In RustPosix, the file offsets are stored inside process fd tables and not in the open file table. which doesnt cause any issues when independent processes are using same files, but since there is no way to share a file offset, this causes unexpected behaviour in fork syscall case.
How is this Tested?
With Buffered and unbuffered calls like fprintf and dprintf along with direct write syscalls.
verified this behaviour as the behaviour falls in expected case when using lseek manually and writing across processes.
Description
Parent and child processes overwrite each others output, when using shared files. This is happening due to lack of a shared file offset across processes. In traditional UNIX systems and probably also in Linux systems, the file structure is as follows:
file descriptors in process fd table -> kernel level open file table -> vnode/inode. and file offsets are stored in kernel level open file table.
Cases:
when independent processes open the same file.
In this case each process will have a fd in its own process table, which will be pointing to an entry in kernel open file table. so even kernel open file table will have two entries each from corresponding processes pointing to the same inode/vnode. so in this case file offsets are completely independent as they are two different entries in open file table. and overwriting is normal behaviour.when forking happens and child and parent process write to the same file.
Assuming Atomic writes each process will have its own entry of fd in its process table, which points to the same entry in kernel open file table. so both fds point to the same entry in the open file table. Thus sharing the file offset and each of them update this as and when writes happen.Why this behaviour?
In RustPosix, the file offsets are stored inside process fd tables and not in the open file table. which doesnt cause any issues when independent processes are using same files, but since there is no way to share a file offset, this causes unexpected behaviour in fork syscall case.
How is this Tested?
With Buffered and unbuffered calls like fprintf and dprintf along with direct write syscalls.
verified this behaviour as the behaviour falls in expected case when using lseek manually and writing across processes.
References
https://www.cs.rpi.edu/academics/courses/fall04/os/c18/#:~:text=When%20a%20file%20is%20first,to%20the%20next%20unread%20byte.
The text was updated successfully, but these errors were encountered: