[haiku-commits] Re: r37836 - haiku/trunk/src/system/kernel/fs
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Tue, 03 Aug 2010 08:07:13 +0200
"Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx> wrote:
> Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> > On 2010-08-02 at 11:43:29 [+0200], axeld@xxxxxxxxxxxxxxxx wrote:
> > > * I see no reason for the fActive check here. Until Ingo
> > > enlightens
> > > me, this
> > > fixes bug #5947, IOW BePDF should now close fine again :-)
> > I believe the case for which you want to change the behavior --
> > closing an FD
> > while another thread is still reading from/writing to it -- doesn't
> > have
> > well-defined semantics according to POSIX. Though I certainly agree
> > that it
> > makes sense to unblock waiting threads. I would, however, rather
> > return an
> > error (e.g. EBADF) to indicate such situation.
> Actually, this is not what this is aiming at. The code hung already
> if
> one end blocked at reading, and I only closed the writer without ever
> having written anything.
Sorry, I must have been paralyzed when I wrote that: it's exactly what
this aimed at, and I agree, EBADF would be a better exit code.
Furthermore, the code still doesn't even work correctly in case there
is more than a single reader.
> > Anyway, I think your change breaks the opening phase. The pipe
> > becomes
> > active
> > (fActive) as soon as both ends have opened. As long as only one end
> > is open
> > and someone tries to read from respectively write to that end the
> > call has to
> > block -- which you broke with your change. So, please find another
> > solution.
> You are mistaken, this is not what I changed.
>
> Inode::WriteDataToBuffer() will still wait until a reader become
> available - it will just not try to write if the writer has been
> closed
> already (which shouldn't matter at all, the only thing that is not
> done
> practically is calling NotifyBytesWritten(0)).
>
> Inode::ReadDataFromBuffer() will not wait anymore if there is no write
> anymore, and that's actually required by POSIX AFAICT, quoting
> OpenGroup: "if no process has the pipe open for writing, read() shall
> return 0 to indicate end-of-file." This is what happens now, but this
> did not always work before.
It did not work before if the file descriptor had been closed in the
mean time, at least the rest is okay, I guess :-)
I'll have another look to find a better solution that does return the
correct error code.
Bye,
Axel.
Other related posts:
