David,
True. Even though there is a point in making the kernel detect and
behave consistently in this case applications (often) end up with
their own mess they cannot easily handle. A few more use cases would
now work OK but probably not enough to make the improvement worthwhile.
Thanks,
> 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?
> Fredrik
Since there's no atomic "unlock and read" function, any code that could ever
close
Alan,
Alan Cox wrote:
Given that 99.99% of programs don't appear to care and you materially
slow down a critical path for every read and write I'm skeptical.
I've made required_fds a struct list_head list to accommodate for
multiple fd:s (not sure that's absolutely needed though), so a coupl
> 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?
Given that 99.99% of programs don't appear to care and you materially
slow down a critical path for every read
Paul,
Paul Jackson wrote:
You suspected correctly - Apple Mail line wrapped it at 72 columns
(added newlines in any line going past column 72.) This makes it
impossible to apply the patch without alot of hand editing.
Of course, sorry about that. New try!
Regarding the FIXME: Marking bad fd:
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 fil
> For (1), a simple scenario has two threads: a reader and a watchdog.
> The reader thread is stuck in a blocking read of an unreliable pipe.
> The watchdog thread is designed to cancel the blocking read using
> close on the reader's fd.
The reader still has the fd open so the fd is not yet
Fredrik wrote:
> required-fds.patch (not sure Apple Mail can handle this properly
> though...):
You suspected correctly - Apple Mail line wrapped it at 72 columns
(added newlines in any line going past column 72.) This makes it
impossible to apply the patch without alot of hand editing.
As you
Hello!
The attached patch attempts to improve read/write/close system call
reliability when used with pthreads and pipes. At least two issues
are handled:
1. Read/write system calls hanging indefinitely when the fd is closed
by another thread.
2. Read/write fd (reuse) alias problems in
9 matches
Mail list logo
