This is the mail archive of the
mailing list for the libstdc++ project.
Re: [Patch/RFC] Fix libstdc++/9533
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: libstdc++ at gcc dot gnu dot org
- Cc: pcarlini at unitus dot it
- Date: Mon, 17 Mar 2003 14:08:51 -0600
- Subject: Re: [Patch/RFC] Fix libstdc++/9533
- References: <3E707F98.firstname.lastname@example.org>
I'm not super keen on this. It feels like hacks on top of hacks. The
test cases are ok, of course, with the renames on temporary files.
It was immediately obvious to me that my patch to libstdc++/6746 was
wrong, which is why it is not on any other branches. Sadly, that was
right in the middle of wedding insanity for me and I was in a pretty
flaky mindset, so I never got back to this. However, I did discuss this
issue with Ulrich and he suggested a better way to handle this, I think.
I've appended his response below.
I think it might be best to remove the patch for 6746 entirely, and
start over. My real wish is to separate out the buffered/unbuffered
classes though, before much more work on this kind of issue happens.
However, this after the testsuite work, which I judge to be critical at
this point for io work to proceed. So, I don't know what to say.
I would like to freeze the 27_io testsuite at some point today, after
you are done checking in patches. Ok?
> I'm trying to triage some of the C++ io bugs. One of the things I found
> is related to an offhand comment I made a while ago, about using
> non-blocking opens for input streams.
> In the following:
> ifstream ifs("tmp");
> size_t i = ifs.rdbuf()->in_avail();
That's a common problem. The in_avail function should, in case the read
buffer is empty, use poll or select. I think using fcntl() to select
non-blocking mode isn't that good since it affects duplicates of the
if (read-buffer not empty)
struct pollfd pfd;
pfd.fd = ifs.fileno();
pfd.events = POLLIN;
if (poll (pfd, 1, 0) > 0)
> My temporary solution, which passes all my tests, is to combine the
> underflow with an open mode switch of
> fcntl(fd, F_SETFL, 0_NONBLOCK)
> for input streams. I think this only impacts fifos, correct?
Nope, this affects all file operations. Theoretically read/write could
block on normal files. They definitely block on socket operations,