How to tell if ifstream has buffered unread data?

How to tell if ifstream has buffered unread data?

Post by Eylon Casp » Wed, 07 Aug 1996 04:00:00



Question - how do you determine if a C++ ifstream has buffered any
           unread data?  (without a blocking call like peek() or get())

I have some socket-based communication code where messages are sent
through C++ streams (ifstream/ofstream) bound to stream-type sockets.
The sockets are blocking, but I don't want the input-parsing code
to block on reads.  So I am using the select() call on the ifstream's
file descriptor to determine whether there is any unread data on the
ifstream.  But select() isn't accurate -- sometimes it claims that
there is no unread data when the ifstream still hasn't parsed all
the messages from the socket.

I think that this is a C++ stream buffering issue.  It may be that
calls to ifstream.operator>>() (for parsing input) buffer all available
data from the socket into a private buffer.  Then select() really sees
no unread data on the socket's file descriptor, even when my code
has not parsed all the socket messages from the ifstream.

So the question is - how do I tell when the ifstream has buffered
data available?  (using non-blocking calls)  Is there some member
function that tells you?  What do gcount() and gtell() do?

  thanks,

Eylon Caspi
Naval Research Lab, D.C.
Tel. (202) 767-3107

 
 
 

How to tell if ifstream has buffered unread data?

Post by Jeff Dickso » Thu, 08 Aug 1996 04:00:00



>Question - how do you determine if a C++ ifstream has buffered any
>           unread data?  (without a blocking call like peek() or get())

>I have some socket-based communication code where messages are sent
>through C++ streams (ifstream/ofstream) bound to stream-type sockets.
>The sockets are blocking, but I don't want the input-parsing code
>to block on reads.  So I am using the select() call on the ifstream's
>file descriptor to determine whether there is any unread data on the
>ifstream.  But select() isn't accurate -- sometimes it claims that
>there is no unread data when the ifstream still hasn't parsed all
>the messages from the socket.

>I think that this is a C++ stream buffering issue.  It may be that
>calls to ifstream.operator>>() (for parsing input) buffer all available
>data from the socket into a private buffer.  Then select() really sees
>no unread data on the socket's file descriptor, even when my code
>has not parsed all the socket messages from the ifstream.

>So the question is - how do I tell when the ifstream has buffered
>data available?  (using non-blocking calls)  Is there some member
>function that tells you?  What do gcount() and gtell() do?

The ioctl with the FIONREAD request works for me. You pass the address of a
long and the number of unread bytes are placed in it. On my system (Sun OS
4.1.2) FIONREAD is duscussed in the man page for filio.

 
 
 

How to tell if ifstream has buffered unread data?

Post by Eylon Casp » Thu, 08 Aug 1996 04:00:00


  ...

Quote:

> So the question is - how do I tell when the ifstream has buffered
> data available?  (using non-blocking calls)  Is there some member
> function that tells you?  What do gcount() and gtell() do?

Here is one answer - the streambuf class has a member
in_avail() which returns non-zero if the stream has unread
buffered data.  It can be accessed as:

        my_ifstream.rdbuf()->in_avail();

Now the question is whether the streambuf class interface is
standardized?  i.e. does streambuf::in_avail() exist in all
C++ compilers?  I have found it in g++, Centerline, and Sun
SPARCworks C++ compilers (all on UNIX), but each implementation
has a slightly different meaning.  The Centerline C++ version
returns the number of unread buffered characters, but the g++
2.7.0 version returns only 1 or 0.

--
Eylon Caspi
Naval Research Lab, D.C.
Tel. (202) 767-3107

 
 
 

How to tell if ifstream has buffered unread data?

Post by Dietmar Kue » Fri, 09 Aug 1996 04:00:00


Hi,
: Question - how do you determine if a C++ ifstream has buffered any
:            unread data?  (without a blocking call like peek() or get())

You might try 'instream.rdbuf()->in_avail()' (if it is already
supported by your IOStreams library; at least it is part of the
standard C++ library). I think for 'ifstream' it should do what you
want (i.e. 'showmanyc()' will always return '0' such that 'in_avail()'
always return the number of characters).

: So the question is - how do I tell when the ifstream has buffered
: data available?  (using non-blocking calls)  Is there some member
: function that tells you?  What do gcount() and gtell() do?

'gtell()' is not a standard function and 'gcount()' returns the number
of characters extracted by the last call to an unformatted input
function for the object.
--

<http://www.informatik.uni-konstanz.de/~kuehl/>
I am a realistic optimist - that's why I appear to be slightly pessimistic

 
 
 

1. Having a Sun tell the UPS to cut the power

We have a UPS, which is monitored by a daemon. When the UPS
detects a main power failure, the daemon will initiate an
ordered shutdown of a Sparc 10 system. As a last thing in the
shutdown process, we would like the ups to cut the power,
in order to save its batteries. The question is how to
do this, without damaging the filesystems on the Sparc.

Basically what I would like to do is to have a process (let's
call it the zapper) initiated by the upsdaemon in case of
power failure which kills other processes on the system in
the following order:

  1. All user processes (excluding uid root, bin, daemon) are
     sent the signal TERM.
  2. Ten seconds later, all the processes, not yet dead, are sent
     the signal KILL.
  3. All processes except swapper, init, pagedaemon, and zapper are
     sent TERM and a bit later KILL if they didn't get the message.

We are now left with four processes on the system. Zapper now
issues a sync. After the sync is done, the question is if zapper
can safely tell the ups to cut the power, without damaging the
file systems.

Another possibility at the last stage is to request the ups
to cut the power, and then run the "halt" program. There should
be some milliseconds before the system falls, and this might
be enough to run the halt program?

Please answer by email, as we do not have net access here in
the company yet.

--
Dov Grobgeld
Orbotec
Yavne, Israel

2. very slow connection!

3. Having trouble with buffered input

4. Could not get a printer off router to print in CUPS

5. How can i tell how full UDP receive buffer is - Solaris7?

6. [COMPAT] compat_sys_fcntl{,64} 1/9 Generic part

7. Having problem hooking up Seagate 4.0gb drive to Data General Avion 5500?

8. ditroff

9. Anybody else having problems with missing data using AHA-2940???

10. Still having problems getting data from GList

11. anybody can tell me about mouse data format?

12. Unbuffering buffered data!

13. Buffers, disk cache, and validating data