Re: Improving read/write/close system call reliability when used with pthreads

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Alan,

Alan Cox wrote:
The reader still has the fd open so the fd is not yet closed. This seems completely sane to me. Closing the *writer* fd would create an EOF which
is the proper response.

The fd is removed from the file descriptor table, but sure the file (as in the kernel struct file * pointer) is still valid. The problem is that the fd used when entering the system call, as an alias for the file pointer, is no longer valid. As a consequence, -ERESTARTSYS no longer works reliably.

Second problem is that a process may not always have access to the writer fd and therefore may not be able to close it. So when closing the reader fd the process has to rely on the following:

- Having a signal such as SIGALRM wake up the reader (in case the writer misbehaves indefinitely). This results in -EBADF returned, provided:

- Hope that the fd has not been reused meanwhile (in which case the reader likely will begin reading the wrong file when it wakes up).

Applications can take either of two approaches:

1) Never close reader fd, but wouldn't it be practical to be able to make things like a threaded watchdog?

2) Do close reader fd, but what results can then applications reliably expect? What would be the sane intention of applications closing reader fd? Do programmers expect all of the current results?

POSIX appears to leave it "implementation-defined" provided I interpret this correctly, of course. So wouldn't it be great to make one of the current results a reliable feature?

(A "reader" could be a "writer" above for similar cases.)

All the best,
Fredrik

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux