This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch/RFC] Fix libstdc++/9533


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?

??

best,
benjamin

-------------------

> 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
file descriptor.


   if (read-buffer not empty)
     return true;

   struct pollfd pfd[1];
   pfd[0].fd = ifs.fileno();
   pfd[0].events = POLLIN;
   if (poll (pfd, 1, 0) > 0)
     return true;

   return false;



> 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,
fifo, etc.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]