non-blocking file access possible in c++?

[Mario]

[Topic also posted in alt.comp.lang.l earn.c-c++]

Hello,

I couldn't find a solution to the following problem (tried
google and dejanews), maybe I'm using the wrong keywords?

Is there a way to open a file (a linux fifo pipe actually) in
nonblocking mode in c++? I did something ugly like

--- c/c++ mixture ---
mkfifo( "testpipe", 777);
int fdesc = open( "testpipe", O_RDONLY|O_NONB LOCK);
while( true)
{
bytes_read = read( fdesc, inbuffer, 255);
if( bytes_read > 0)
std::cerr << "Read " << inbuffer << std::endl;
else
{
std::cerr << "Nothing to read here!" << std::endl;
usleep( 250000);
}
}
--- end ---

Now I want the same result in c++, there has to be some flag
or fctrl or something?

Thanx for any help,

Mario

[Kanenas]

Re: non-blocking file access possible in c++?

On Wed, 13 Apr 2005 11:27:56 +0200, Mario <supermar@gmx.d e> wrote:
[color=blue]
>[Topic also posted in alt.comp.lang.l earn.c-c++]
>
>Hello,
>
>I couldn't find a solution to the following problem (tried
>google and dejanews), maybe I'm using the wrong keywords?
>
>Is there a way to open a file (a linux fifo pipe actually) in
>nonblocking mode in c++? I did something ugly like
>[/color]
[...]

Using the C I/O functions is an option. If you want the type-safety
of C++ I/O operations or an OO interface, you could layer a class on
top of the C I/O.

A non-C++ standard, non-portable alternative would be to get a C++
library which supports FIFOs or Unix domain sockets (e.g. GNU Common
C++'s UnixSocket). These tend to support non-blocking I/O. That this
is of limited portability shouldn't be any hindrance in your case.

Another option is to use istream::readso me, which is probably
supported by your c++ library. It reads up to the number of
characters remaining in the stream buffer into a character array. If
the stream buffer is empty, no characters are copied. This may not be
quite the same as non-blocking input because of the difference between
an input buffer and an input sequence. If an input buffer is empty
but its associated input sequence currently has available characters,
readsome() will still copy 0 characters. Note that for an ifstream, I
would expect buffered input to have this problem. If it's impossible
to have an empty buffer but available input, readsome should give you
non-blocking input. Try making an ifstream with a small buffer size
(say, 2) for a file larger than the buffer size and then call readsome
for the ifstream. Of course, if readsome works on your system that
doesn't mean this is a complete solution.

You can use 'in.rdbuf()->in_avail()' to check whether istream in's
buffer has any characters left to be read, but you may have the same
issue as with readsome (readsome usually uses in_avail). in_avail()
!= 0 means get() will not block, but in_avail() == 0 only means get()
MAY block. Using in_avail is what Stroustrup suggests to avoid
blocking. For example:
inline bool wouldblock(std: :istream& in)
{return in.rdbuf()->in_avail() == 0;}
A better implementation of wouldblock may depend on the internals of
stream buffers (see local documentation of showmanyc(), which the
local in_avail() may already call).

If you want to make input via '>>' non-blocking, you could extend
i(f)stream. You could also extend the appropriate stream buffer class
(called perhaps "unblockable_st reambuf") and make blocking during
reads dependent on some state of unblockable_str eambuf. Look at the
underflow and uflow methods of streambuf before embarking on this
path. Extending stream buffers is probably a better option than
extending i(f)stream as blocking behavior is more related to a stream
buffer than a stream. It also may be easier to implement and better
behaved in the face of the polymorphic behavior of i(f)stream.

You could also make types which use non-blocking input. e.g.
template <typename _Type>
struct Nonblocked {
_Type& val;
Nonblocked(_Typ e& v) : val(v) {}
/*
Nonblocked::wou ldblock allows for specializations which have
more appropriate definitions of wouldblock (e.g. a Nonblocked
to input pairs as "(first, second)" which would fail if input
stopped at "(first, " and no other characters are currently
available in the input sequence)
*/
inline bool wouldblock(std: :istream& in)
{return ::wouldblock(in );}
};

template <typename _Type>
std::istream& operator>>(std: :istream& in, Nonblocked<_Typ e>& n)
{
//how to signal nothing was read? set failbit for in?
if (n.wouldblock(i n)) in.setstate(ios _base::failbit) ;
else in >> n.val;
return in;
}

...
int i;
fin >> Nonblocked<int> (i);
This option looks a little odd to me. Note I couldn't think of a good
name for the class template "Nonblocked ", perhaps a sign that this
design stands on shaky ground. A better implementation of
"wouldblock " than that given above is also needed.

You could even abuse the tying mechanism to tie an i(f)stream (call it
'in') to an "ostream" which sets/unsets failbit for itself depending
on the value of wouldblock(in), thus enabling/preventing input from
'in'. Due to the polymorphic behavior of ostream::flush, your
class(es) may not be able to take control until the sync() method of
the tied ostream's buffer is called (ostream::sync is non-virtual and
calls the non-virtual streambuf::pubs ync, which calls the virtual
streambuf::sync ), so you may need to extend streambuf for this to
work. If the i(f)stream was tied to some other ostream (call it
'out'), the "ostream" better flush 'out' somewhere along the way. To
switch between blocking and non-blocking, tie/untie the "ostream"
to/from 'in'. All in all, this is an ugly and effortful option, but
it's still an option.

If you decide to try extending any of C++'s I/O classes, consider the
sentry class and/or the ios_base storage/callback mechanism. Combine
this with tie() abuse and you can add a block/nonblock state to 'in'
so you can easily switch between blocking and non-blocking input with
manipulators.

If you haven't seen it yet, check out the C++ annotations for input
streams:

http://www.icce.rug.nl/documents/cplusplus/cplusplus05.html#l78

C++ annotations, main page:

http://www.icce.rug.nl/documents/cplusplus/

Kanenas

[Mario]

Re: non-blocking file access possible in c++?

Hy,

Kanenas wrote:[color=blue]
> A non-C++ standard, non-portable alternative would be to get a C++
> library which supports FIFOs or Unix domain sockets (e.g. GNU Common
> C++'s UnixSocket). These tend to support non-blocking I/O. That this
> is of limited portability shouldn't be any hindrance in your case.[/color]
That would be a great solution, since I have to use cc++ anyways!
Could you point out a little hint where to look in the docs? cc++ doesn't
have a non-blocking file::open() call, (or I missed it,) but maybe there
is a way arround?
[color=blue]
> Another option is to use istream::readso me, which is probably
> supported by your c++ library. It reads up to the number of[/color]
That is actually a great idea, but won't work for me, as I need non-
blocking file-i/o for only one reason:
to read from, and write to a pipe at the same time, from different
programs.

With the small c-prog I posted, that works perfectly, you could
echo "hello world" >> fifopipe
from the shell and the prog would read it from there. But as soon as I
don't open the pipe non-blocking, it won't work anymore...
Maybe I'm doing something wrong?
[color=blue]
> If you haven't seen it yet, check out the C++ annotations for input
> streams:
> http://www.icce.rug.nl/documents/cpl...lus05.html#l78
> C++ annotations, main page:
> http://www.icce.rug.nl/documents/cplusplus/[/color]
I'll check these again, thx for the link, haven't seen them yet.

Mario

[Kanenas]

Re: non-blocking file access possible in c++?

On Thu, 14 Apr 2005 11:52:55 +0200, Mario <supermar@gmx.d e> wrote:
[color=blue]
>Hy,
>
>Kanenas wrote:[color=green]
> > A non-C++ standard, non-portable alternative would be to get a C++
>> library which supports FIFOs or Unix domain sockets (e.g. GNU Common
>> C++'s UnixSocket). These tend to support non-blocking I/O. That this
>> is of limited portability shouldn't be any hindrance in your case.[/color]
>That would be a great solution, since I have to use cc++ anyways!
>Could you point out a little hint where to look in the docs? cc++ doesn't
>have a non-blocking file::open() call, (or I missed it,) but maybe there
>is a way arround?
>[/color]
By "cc++", do you mean C/C++ (a mixture of C and C++) or is it a typo
for "C++"?

If you want to know more about GNU Common C++, go to:

http://www.gnu.org/software/commoncpp/

As for non-blocking stream I/O, the only support the standard C++
library provides which I'm aware of are the streambuf::in_a vail and
istream::readso me methods mentioned in my previous post.
[color=blue][color=green]
>> Another option is to use istream::readso me, which is probably
>> supported by your c++ library. It reads up to the number of[/color]
>That is actually a great idea, but won't work for me, as I need non-
>blocking file-i/o for only one reason:
> to read from, and write to a pipe at the same time, from different
> programs.
>[/color]
istream::readso me should work with an ifstream, and an ifstream should
be able to open a FIFO, so istream::readso me should work for you.
You'll still be responsible for race conditions and file locking.

Is a FIFO required, or will other interprocess communication
structures (such as Unix domain sockets) work?
[color=blue]
>With the small c-prog I posted, that works perfectly, you could
> echo "hello world" >> fifopipe
>from the shell and the prog would read it from there. But as soon as I
>don't open the pipe non-blocking, it won't work anymore...
>Maybe I'm doing something wrong?
>[/color]
This suggests your true issue is whatever makes the reader not "work
anymore" rather than opening a non-blocking stream. Non-blocking I/O
may be a solution, but merely an indirect one. What, exactly, stopped
working? What happens if you open the pipe as an ifstream rather than
via open()? When I tested your basic approach (with a few corrections
and additions, keep reading for the important one), I didn't see any
issues; the reader read from the pipe whenever anything was put in.
The only difference was that for blocking I/O, the reader paused the
first time through the loop until something was written to the pipe.
[color=blue]
> --- c/c++ mixture ---
>mkfifo( "testpipe", 777);[/color]

You probably want "0777", which is an octal number, rather than "777",
which is base 10, for the mode. Decimal "777" corresponds to octal
"01411", and will give the pipe the permissions "r----x--x" plus the
sticky bit, less the process's umask. This will make
echo "hello world" >> testpipe
fail as it won't have write permission.
[color=blue]
>int fdesc = open( "testpipe", O_RDONLY|O_NONB LOCK);[/color]

Don't forget to test that fdesc > 0 in your production code.
[color=blue]
>while( true)
>{
> bytes_read = read( fdesc, inbuffer, 255);
> if( bytes_read > 0)[/color]
In production code, the size of inbuffer better be a parameter rather
than a constant. read() won't terminate strings, so you need to do it
yourself. As you won't want to overwrite the last character if read
fills inbuffer, have read() read 1 less than the size of inbuffer
(call 'read(fdesc, inbuffer, bufsize-1)'). Then terminate the buffer
as below.
{
inbuffer[bytes_read] = 0;[color=blue]
> std::cerr << "Read " << inbuffer << std::endl;[/color]
}[color=blue]
> else
> {
> std::cerr << "Nothing to read here!" << std::endl;
> usleep( 250000);[/color]

select() is a much better alternative to polling via sleeping. Note
select() will mix more C into your program and is thus appropriate
only if a C/C++ I/O approach is better than pure C++ I/O. If you want
to know more about select(), check its man page, try a google search
or get a good book on Unix development such as "Advanced Unix
Programming" by Marc J. Rochkind.
[color=blue]
> }
>}[/color]


Kanenas