On Wed, 13 Apr 2005 11:27:56 +0200, Mario <su******@gmx.de> wrote:
[Topic also posted in alt.comp.lang.learn.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
[...]
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::readsome, 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_streambuf") and make blocking during
reads dependent on some state of unblockable_streambuf. 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(_Type& v) : val(v) {}
/*
Nonblocked::wouldblock 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<_Type>& n)
{
//how to signal nothing was read? set failbit for in?
if (n.wouldblock(in)) 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::pubsync, 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/cpl...lus05.html#l78
C++ annotations, main page:
http://www.icce.rug.nl/documents/cplusplus/
Kanenas
