Re: fileevent saying there's something to read but there isn't ?!



Cameron Laird wrote:
In article <WbydnWOJTq8Dw-7Z4p2dnA@xxxxxxxxxxx>,
David Gravereaux <davygrvy@xxxxxxxxx> wrote:
Cameron Laird wrote:
.
.
.
Yet fileevent keeps firing on the channel...

I haven't set any special options on the channel.

How can I prevent this behaviour?
.
.
.
It's a feature.

The first step in processing a fileevent can/should be to test [eof $channel].

Umm, sorta..

If after the last read command ([gets] or [read], actually) in your
fileevent proc had tested for eof, then you would know then.

Please test for EOF *AFTER* your [read] or [gets]!
.
.
[lot more detail]
.
Davy's ABSOLUTELY right. I know better; 'fact, I've been correcting
what I wrote for most of the last decade. What I wrote is simply
wrong--I was trying to say something different, and utterly lost
track of my point.

So, again, Davy has it: [eof] only AFTER [read] or [gets].

The conclusion for the original poster should be that, yes, it's
important to check for [eof] (although, as others pointed out,
there are circumstances where "-1 == [gets ..." is an effective
substitute for a literal [eof]).


Cameron,

Sorry I pounced on you.. I didn't mean to. I have some raw nerves with
regards to some incomplete aspects of the channel system; both
documentation and logic.

The man page for [eof] mostly implies it:

"Returns 1 if an end of file condition occurred during the most recent
input operation on channelId (such as gets), 0 otherwise."

But doesn't actually say you must/should check for [eof] after the
[read] or [gets], nor does the very long man page on the channel driver
API say it is the responsibility of the channel driver to manufacture
fake readable events on an unclosed and eof'd channel so a pre-checked
(ill placed) [eof] test in a fileevent callback can get proper closure.

oh god.. I seem to be entering into rant mode...
.