开发者

is pwrite after dup race safe?

开发者 https://www.devze.com 2022-12-13 15:39 出处:网络
On Linux pwrite operation 开发者_如何学编程(which is seek+write) is atomic, meaning doing pwrite-s in multiple threads with one file descriptor is safe.

On Linux pwrite operation 开发者_如何学编程(which is seek+write) is atomic, meaning doing pwrite-s in multiple threads with one file descriptor is safe. I want to create file descriptor duplicate, using dup(). Now, having fd1 and fd2 - will pwrite-s work as expected, or there's danger of race condition?


File descriptor pairs created through dup share the same file status, (e.g. an lseek operation on one file descriptor will affect the other), because they refer to the same entry in the process open files table, which means they are essentially indistinguishable. The only thing they do not have in common is file descriptor flags, (e.g. FD_CLOEXEC.)

From the man page:

After a successful return from dup() or dup2(), the old and new file descriptors may be used interchangeably. They refer to the same open file description (see open(2)) and thus share file offset and file status flags; for example, if the file offset is modified by using lseek(2) on one of the descriptors, the offset is also changed for the other.

Given that dup allows you to use the two file descriptors interchangeably, (because they refer to the same file in the process file table) I assume this implies that calling pwrite on one would be the same as calling it on the other, and thus be atomic.


I think pwrite is an atomic operation if the number of bytes you're writing is less than PIPE_BUF of the pipe you're writing to (from the POSIX programmer's manual).

0

精彩评论

暂无评论...
验证码 换一张
取 消