buffering of stdio streams

[Chris McDonald]

[hopefully of wide interest, and not too OT]

Under Linux, I'm using select() to detect when any of a collection of
socket descriptors is ready for reading. Associated with each socket
descriptor is a FILE pointer, obtained via fdopen(sd, "r"). When any
socket descriptor becomes ready, I call fgets(...., fp) to read a line
of textual input.

However, I suspect that if more than one line of input is ready on the
socket descriptor, that fgets() reads it all in and places it in the
stdio buffer associated with the FILE pointer. Thus, I'm not able to
tell when the "2nd" line of input arrives, because the socket descriptor
is not ready, and the 2nd line has already arrived, and is sitting in
the FILE's buffer.

How can I tell if anything resides in the FILE's buffer, without
performing another blocking fgets() ?

Thanks,

_______________________________________________________________________________
Dr Chris McDonald E: (e-mail address removed)
Computer Science & Software Engineering W: http://www.csse.uwa.edu.au/~chris
The University of Western Australia, M002 T: +618 6488 2533
Crawley, Western Australia, 6009 F: +618 6488 1089

 

[Jack Klein]

[hopefully of wide interest, and not too OT]

Under Linux, I'm using select() to detect when any of a collection of
socket descriptors is ready for reading. Associated with each socket
descriptor is a FILE pointer, obtained via fdopen(sd, "r"). When any
socket descriptor becomes ready, I call fgets(...., fp) to read a line
of textual input.

However, I suspect that if more than one line of input is ready on the
socket descriptor, that fgets() reads it all in and places it in the
stdio buffer associated with the FILE pointer. Thus, I'm not able to
tell when the "2nd" line of input arrives, because the socket descriptor
is not ready, and the 2nd line has already arrived, and is sitting in
the FILE's buffer.

How can I tell if anything resides in the FILE's buffer, without
performing another blocking fgets() ?

Thanks,

You need Neither select() nor
fdopen() are part of the C language, they are non-standard extensions
provided by your platform.

 

[Chris McDonald]

[hopefully of wide interest, and not too OT]

.....

You need Neither select() nor
fdopen() are part of the C language, they are non-standard extensions
provided by your platform.

A tiresome response.

_______________________________________________________________________________
Dr Chris McDonald E: (e-mail address removed)
Computer Science & Software Engineering W: http://www.csse.uwa.edu.au/~chris
The University of Western Australia, M002 T: +618 6488 2533
Crawley, Western Australia, 6009 F: +618 6488 1089

 

[Martin Ambuhl]

On Fri, 6 Aug 2004 04:40:16 +0000 (UTC), Chris McDonald

[hopefully of wide interest, and not too OT]

.....

You need Neither select() nor
fdopen() are part of the C language, they are non-standard extensions
provided by your platform.

A tiresome response.

Yes, but these tiresome off-topic questions posted by people with no
sense of proper behavior in newsgroups evoke such completely correct
responses. How does someone get a doctorate without getting a clue? By
going to school in Australia.

 

[Richard Bos]

[hopefully of wide interest, and not too OT]

Under Linux, I'm using select()

This _is_ off-topic.

How can I tell if anything resides in the FILE's buffer, without
performing another blocking fgets() ?

This _is_ off-topic.

And you'd have known this, had you but had the common decency to browse
the FAQ before posting, as any civilised Usenetter does.

<http://www.eskimo.com/~scs/C-faq/q19.2.html>. HTH; HAND.

Richard

 

[CBFalconer]

[hopefully of wide interest, and not too OT]
.....

You need Neither select()
nor fdopen() are part of the C language, they are non-standard
extensions provided by your platform.

A tiresome response.

_______________________________________________________________________________
Dr Chris McDonald E: (e-mail address removed)
Computer Science & Software Engineering W: http://www.csse.uwa.edu.au/~chris
The University of Western Australia, M002 T: +618 6488 2533
Crawley, Western Australia, 6009 F: +618 6488 1089

Interesting. An allegedly educated in the field individual is
incapable of preparing correct signatures with a proper sig
marker, is incapable of checking the usual practices on a
newsgroup before butting in with off-topic material, and then
responds to polite and helpful advice about where to get
appropriate information with a snippy answer.

This all speaks very poorly of one or more of the McDonald clan,
The University of Western Australia (and its department of
Computer Science), Australians, or Western Australians. I am not
sure whether manners or education are at fault. At any rate the
so-called Doctor is definitely in the boor category.

Somehow I doubt that all Australians should be so categorized.
Maybe some will respond and better place the category limit?

 

[Chris McDonald]

Yes, but these tiresome off-topic questions posted by people with no
sense of proper behavior in newsgroups evoke such completely correct
responses. How does someone get a doctorate without getting a clue? By
going to school in Australia.

A tiresome ad hominem response.
Good luck with your doctorate.

_______________________________________________________________________________
Dr Chris McDonald E: (e-mail address removed)
Computer Science & Software Engineering W: http://www.csse.uwa.edu.au/~chris
The University of Western Australia, M002 T: +618 6488 2533
Crawley, Western Australia, 6009 F: +618 6488 1089

 

[Chris McDonald]

[hopefully of wide interest, and not too OT]

Under Linux, I'm using select()

This _is_ off-topic.

Yes, I _knew_ it was off-topic, and even stated this in my article.
Your point is?

And you'd have known this, had you but had the common decency to browse
the FAQ before posting, as any civilised Usenetter does.

<http://www.eskimo.com/~scs/C-faq/q19.2.html>. HTH; HAND.

Thank you for this helpful response.

 

[Chris McDonald]

Interesting. An allegedly educated in the field individual is
incapable of preparing correct signatures with a proper sig
marker, is incapable of checking the usual practices on a
newsgroup before butting in with off-topic material, and then
responds to polite and helpful advice about where to get
appropriate information with a snippy answer.

This all speaks very poorly of one or more of the McDonald clan,
The University of Western Australia (and its department of
Computer Science), Australians, or Western Australians. I am not
sure whether manners or education are at fault. At any rate the
so-called Doctor is definitely in the boor category.

Somehow I doubt that all Australians should be so categorized.
Maybe some will respond and better place the category limit?

Your post is off-topic, but that's OK if you're in the net police, isn't it?


Another tiresome ad hominem response.
Axis of the killing, and now a free trade agreement - why do we bother?
Yeah, yeah, we know, don't waste your precious bandwidth.

 

[Richard Bos]

[hopefully of wide interest, and not too OT]

Under Linux, I'm using select()

This _is_ off-topic.

Yes, I _knew_ it was off-topic, and even stated this in my article.
Your point is?

My point is that if you'd had half a brain, or even the civility
expected of normal humans, you would have known better than to post this
here, where it is _off_ _topic_. Of course, that would have cost you all
of, oh, perhaps three minutes searching for a newsgroup where it is
on-topic, but your time is, clearly, much more important than that of
the readers of this newsgroup. Pity, then, that you've probably already
spent more time posting holier-than-thou, self-important snide responses
than you would have if you'd been a decent netizen in the first place.

But then, what else could we expect from a descendant of criminal
exiles, and a sandgroper to boot?

Thank you for this helpful response.

I hope it taught you something. Apparently, nothing else has.

Richard

 

[Chris McDonald]

My point is that if you'd had half a brain, or even the civility
expected of normal humans, you would have known better than to post this
here, where it is _off_ _topic_. Of course, that would have cost you all
of, oh, perhaps three minutes searching for a newsgroup where it is
on-topic, but your time is, clearly, much more important than that of
the readers of this newsgroup. Pity, then, that you've probably already
spent more time posting holier-than-thou, self-important snide responses
than you would have if you'd been a decent netizen in the first place.

The pot calling the kettle black.
How does one apply for membership to your precious net-police squad?

It's a newsgroup guys, get over it.
It's a medium for exchange and education.

Oh, quick, there was a post about free iPods.
You guys better get over there and shoot 'em down quick.

But then, what else could we expect from a descendant of criminal
exiles, and a sandgroper to boot?

There you go again, tiresome.
It must be a Friday thing, and you all have nothing better to do.

_______________________________________________________________________________
Dr Chris McDonald E: (e-mail address removed)
Computer Science & Software Engineering W: http://www.csse.uwa.edu.au/~chris
The University of Western Australia, M002 T: +618 6488 2533
Crawley, Western Australia, 6009 F: +618 6488 1089

 

[Martin Ambuhl]

Chris McDonald wrote:

Your post is off-topic, but that's OK if you're in the net police, isn't it?

You are dead wrong. Please get your lazy butt over to
and learn something? Topicality is topical.

Another tiresome ad hominem response.

Accusing people of ad hominem responses does not make your complete lack
of newgroup etiquette go away. Your labelling as tiresome completely
correct and proper responses to your completely wrong and improper
postings only labels you as a tiresome idiot. You will have to gain
some humanity before you qualify for an ad hominem attack. Does your
university know that you are embarrassing them by claiming to have been
awarded a degree?

 

[Martin Ambuhl]

[hopefully of wide interest, and not too OT]

Under Linux, I'm using select()

This _is_ off-topic.

Yes, I _knew_ it was off-topic, and even stated this in my article.
Your point is?

Then why the hell did you post it? Is your doctorate in trolling?

 

[Richard Tobin]

How can I tell if anything resides in the FILE's buffer, without
performing another blocking fgets() ?

You can't, portably.

Unportably, the answer is likely to be obvious from the definition of
getc in stdio.h: typically it will be a macro that does something very
simple if there are still characters in the buffer, and otherwise
calls a function.

-- Richard

 

[Default User]

A tiresome response.

But correct.



Brian Rodenborn

 

[Default User]

A tiresome ad hominem response.
Good luck with your doctorate.

Oh, another of one of these idjits.


*plonk*




Brian Rodenborn

 

[Default User]

Then why the hell did you post it? Is your doctorate in trolling?

Don't waste time with the guy, it's obvious he's a troll looking for
attention. Plonk him and move on.




Brian Rodenborn

 

[Michael Wojcik]

[hopefully of wide interest, and not too OT]

Well, I for one appreciate the topicality warning.

[in c.l.c terms: I am using stream I/O in an implementation-defined
way]

However, I suspect that if more than one line of input is ready on the
socket descriptor, that fgets() reads it all in and places it in the
stdio buffer associated with the FILE pointer.

Quite possible.

Thus, I'm not able to
tell when the "2nd" line of input arrives, because the socket descriptor
is not ready, and the 2nd line has already arrived, and is sitting in
the FILE's buffer.

Quite possible. There's no standard way to change input buffering
for streams, so there isn't anything you can do about this. (OT:
Even if there were, you wouldn't want to, because the only way to
implement it would be to have the stream read one byte at a time from
the socket, which would be very inefficient.)

How can I tell if anything resides in the FILE's buffer, without
performing another blocking fgets() ?

You can't, within the standard library, unless I'm missing something.
Depending on implementation behavior, you might be able to reliably
get a positive answer with fgetc / ungetc - get a character, showing
there's something in the buffer, and then push it back - but that
won't work if the buffer is empty, since it will cause the stream to
try to read from the source.

OT: I mooted this idea - attaching a stream to a socket - in
comp.protocols.tcp-ip some years ago, and Barry Margolin was quick
to point out a reason or two why it was a bad one (clever though it
might seem on first inspection). You might want to check the Google
archives for that exchange.

Ultimately, I think you're faced with either writing your own code or
finding someone else's implementation to take the obvious approach:
maintain your own buffer, and when you want to check if more data is
ready, check it first, then check the socket if the buffer is empty.

--
Michael Wojcik (e-mail address removed)

This year's runner-up in the All-Usenet Creative Use Of English In A
Quasi-Legal But Probably Completely Ineffectual Signature Statement:

Disclaimer : I am a free denizen of this world and statements are of mine
and solly mine. Nobody dare sue me as you may end up even loosing your
attorney fees. -- Sridhar ([email protected])

 

[CBFalconer]

You are dead wrong. Please get your lazy butt over to
and learn something? Topicality
is topical.


Accusing people of ad hominem responses does not make your
complete lack of newgroup etiquette go away. Your labelling
as tiresome completely correct and proper responses to your
completely wrong and improper postings only labels you as a
tiresome idiot. You will have to gain some humanity before
you qualify for an ad hominem attack. Does your university
know that you are embarrassing them by claiming to have been
awarded a degree?

They should now. I complained to his abuse header address about 6
hours ago.

 

[SM Ryan]

# Under Linux, I'm using select() to detect when any of a collection of
# socket descriptors is ready for reading. Associated with each socket
# descriptor is a FILE pointer, obtained via fdopen(sd, "r"). When any
# socket descriptor becomes ready, I call fgets(...., fp) to read a line
# of textual input.

stdio doesn't handle more sophisticated I/O all that well. Rather than
struggle to make it work, I abandon it in favour of lower level
interfaces, like read() and write(), or more sophisticated libraries
like Tcl_Write and Tcl_Gets.

# However, I suspect that if more than one line of input is ready on the
# socket descriptor, that fgets() reads it all in and places it in the
# stdio buffer associated with the FILE pointer. Thus, I'm not able to
# tell when the "2nd" line of input arrives, because the socket descriptor
# is not ready, and the 2nd line has already arrived, and is sitting in
# the FILE's buffer.

Tcl_Gets works well with non-blocking bufferred reads. You can use the
Tcl C API without using a Tcl interpretter if you want.

Remember the ANS C is driven by greatest common factor politics. Only
those features all corporate sponsors can implement get included.
There's a whole bunch of free library available on nearly every machine,
and which is not shackled to ANSI sponsors.