Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

fstream doesn't play well with named pipes #23077

Open Quuxplusone opened 9 years ago

Quuxplusone commented 9 years ago
Bugzilla Link PR23078
Status NEW
Importance P normal
Reported by surfintheusa@yahoo.com
Reported on 2015-03-30 19:46:11 -0700
Last modified on 2015-04-01 12:35:29 -0700
Version 3.5
Hardware Macintosh MacOS X
CC llvm-bugs@lists.llvm.org, mclow.lists@gmail.com
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also
Given a pipe created at the command line using 'mkfifo my_pipe' and given the
following snippet:

#include <fstream>
#include <iostream>
#include <string>

int main(int, char*[])
{
    std::fstream pipe("my_pipe");
    std::string message;
    while(std::getline(pipe, message) && message != "EXIT")
    {
        std::cout << message << std::endl
    }

    return 0;
}

If I run the program and (from another command prompt) issue the command "echo
banana > my_pipe", nothing gets printed as it appears the call to getline never
returns. The same snippet and scenario with libstdc++ 4.7.2 works as expected.
That is getline returns, cout prints the message and we loop until message is
"EXIT".

MacOS X 10.10.2

clang -v:
Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
Quuxplusone commented 9 years ago

The problem is actually in basic_filebuf<_CharT, _Traits>::underflow().

Around line 595, it calls fread to fill the filebuf's buffer. (by default, 4096 bytes). this read hangs until it can read an entire buffer-full. When it is talking to a file, and the file doesn't have that much data, it gets a short read. When it is talking to a pipe, it just waits until that much data is available.

[ You can test this with the test program by putting 4K or more data into the pipe ]

Quuxplusone commented 9 years ago

Thanks, Marshall, for looking into this.

Is there a possible workaround?

Quuxplusone commented 9 years ago
(In reply to comment #2)
> Thanks, Marshall, for looking into this.
>
> Is there a possible workaround?

I don't have one yet.

I suspect that there isn't a "workaround"; the behavior of basic_filebuf will
probably have to be changed.