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...
.

Relevant Pages

  • Re: tcludp - bug when closing 1-of-2 listening ports
    ... Closing the client channel may trigger a readable fileevent on the server (it does for TCP sockets, not sure if/why it would do the same for UDP), so you should always be prepared for eof there, otherwise your will block indefinitely. ...
    (comp.lang.tcl)
  • Re: tcludp - bug when closing 1-of-2 listening ports
    ... Closing the client channel may trigger a readable fileevent on the server (it does for TCP sockets, not sure if/why it would do the same for UDP), so you should always be prepared for eof there, otherwise your will block indefinitely. ...
    (comp.lang.tcl)
  • Re: fileevent saying theres something to read but there isnt ?!
    ... DG> API say it is the responsibility of the channel driver to manufacture ... DG> [eof] test in a fileevent callback can get proper closure. ... script reads no data, returns, and is immediately invoked ...
    (comp.lang.tcl)
  • Re: gets, fconfigure question
    ... THis log file is being written to quite often, ... the channel ID to make the channel non-blocking, ... I'd rather gets return a -1 if the EOL occurs before EOF. ... non-blocking mode -- this is an operating system thing. ...
    (comp.lang.tcl)
  • Re: fileevent saying theres something to read but there isnt ?!
    ... fileevent proc had tested for eof, ... guaranteed to always work that way for all channel types. ... The fileevent stuff is in Tcl, ... back into Tcl land to test for EOF. ...
    (comp.lang.tcl)