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

[Fredrik Noring]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/