fileevent saying there's something to read but there isn't ?!
Frank Goenninger DG1SBG
I have created a text file with three lines of text in it. I then use
fileevent to have a line by line reading style and had expected that
when I have read the third line of my file that fileevent knows that
there's nothing to read anymore.
Yet fileevent keeps firing on the channel...
I haven't set any special options on the channel.
How can I prevent this behaviour?
Thx for any input.
Best wishes
Frank
Cameron Laird
.
.
It's a feature.
The first step in processing a fileevent can/should be to test [eof $channel].
Ulrich Schöbel
Hi Frank,
check for eof and then close the channel.
Kind regards
Ulrich
Michael A. Cleverly
> I have created a text file with three lines of text in it. I then use
> fileevent to have a line by line reading style and had expected that
> when I have read the third line of my file that fileevent knows that
> there's nothing to read anymore.
>
> Yet fileevent keeps firing on the channel...
>
> I haven't set any special options on the channel.
>
> How can I prevent this behaviour?
Inside your fileevent be sure to test to see if you've reached
the end of the file (use [eof $fp]). As the fileevent man page notes:
"A channel is also considered to be readable if an end of file
or error condition is present on the underlying file or device."
Michael
Frank Goenninger DG1SBG
Yeah, I figure it's a true advantage to have the ability to
read... Sorry for bothering and of course thanks for pointing out...
... to all the posters, of course...
;-)
Best wishes
Frank
Fredderic
> > "A channel is also considered to be readable if an end of file
> > or error condition is present on the underlying file or
> > device."
> Yeah, I figure it's a true advantage to have the ability to
> read... Sorry for bothering and of course thanks for pointing out...
> ... to all the posters, of course... ;-)
Isn't [gets] supposed to throw a -1 if it hits an eof straight off?
I usually use something like { [gets $fd line] < 0 } to decide when
this channel just isn't working for me anymore. Seems to work so far...
I think [read] is supposed to do the same thing, so I've very rarely
actually found myself using the [eof] command at all. But yeah, you DO
have to check SOMEHOW...
Fredderic
Frank Goenninger DG1SBG
Frederic,
thanks for the reply. Yes, I know, I do have to check, but:
In case of a RS232C channel or socket channel I have the behaviour of
fileevent saying "Currently no data there" by NOT firing. Which is
exactly what I need.
Though this is different for a normal file. In this case fileevent
keeps firing. I therefore have to check which type of channel I have
and if it's a file channel I can close it. The procedure that
fileevent calls is sort of a generic dispatch procedure (not even in
Tcl/Tk, but a function in Lisp called via a callback previously
registered as new command via Tcl_CreateCommand)...
Well, at least it works now for sockets and serial ports...
Thanks again.
Frank
Robert Heller
In a message on Sun, 21 May 2006 14:07:37 +0200, wrote :
FGD> Fredderic <put_my_n...@optusnet.com.au> writes:
FGD>
FGD> > On Sat, 20 May 2006 20:20:22 +0200,
FGD> > Frank Goenninger DG1SBG <dont-e...@nomail.org> wrote:
FGD> >
FGD> >> > "A channel is also considered to be readable if an end of file
FGD> >> > or error condition is present on the underlying file or
FGD> >> > device."
FGD> >> Yeah, I figure it's a true advantage to have the ability to
FGD> >> read... Sorry for bothering and of course thanks for pointing out...
FGD> >> ... to all the posters, of course... ;-)
FGD> >
FGD> > Isn't [gets] supposed to throw a -1 if it hits an eof straight off?
FGD> >
FGD> > I usually use something like { [gets $fd line] < 0 } to decide when
FGD> > this channel just isn't working for me anymore. Seems to work so far...
FGD> >
FGD> > I think [read] is supposed to do the same thing, so I've very rarely
FGD> > actually found myself using the [eof] command at all. But yeah, you DO
FGD> > have to check SOMEHOW...
FGD> >
FGD> >
FGD> > Fredderic
FGD>
FGD> Frederic,
FGD>
FGD> thanks for the reply. Yes, I know, I do have to check, but:
FGD>
FGD> In case of a RS232C channel or socket channel I have the behaviour of
FGD> fileevent saying "Currently no data there" by NOT firing. Which is
FGD> exactly what I need.
In the case of a RS232C channel you will never get an EOF and a socket
channel will report EOF when the process at the other end closes the
socket. (I believe that if the process at the other end of the socket
(or pipe) closes the socket (or pipe), the file event will fire, since
eof is a readable event.)
FGD>
FGD> Though this is different for a normal file. In this case fileevent
FGD> keeps firing. I therefore have to check which type of channel I have
FGD> and if it's a file channel I can close it. The procedure that
FGD> fileevent calls is sort of a generic dispatch procedure (not even in
FGD> Tcl/Tk, but a function in Lisp called via a callback previously
FGD> registered as new command via Tcl_CreateCommand)...
FGD>
FGD> Well, at least it works now for sockets and serial ports...
You can always *generically* test for EOF: [eof <some RS232 channel>]
will always return false, [eof <some socket channel>] will return true
if the other end of the socket is closed, and [eof <some file channel>]
will return true at actual EOF.
FGD>
FGD> Thanks again.
FGD>
FGD> Frank
FGD>
Robert Heller -- 978-544-6933
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
hel...@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk
Michael A. Cleverly
> On Sat, 20 May 2006 20:20:22 +0200,
> Frank Goenninger DG1SBG <dont-e...@nomail.org> wrote:
>
> > > "A channel is also considered to be readable if an end of file
> > > or error condition is present on the underlying file or
> > > device."
> > Yeah, I figure it's a true advantage to have the ability to
> > read... Sorry for bothering and of course thanks for pointing out...
> > ... to all the posters, of course... ;-)
>
> Isn't [gets] supposed to throw a -1 if it hits an eof straight off?
It depends on how you call [gets].
[gets $f line] will put the line that was read into the variable $line and
return the number of characters read, or -1 in the case of EOF.
Called merely as [gets $f] then gets returns the line read instead.
Michael
Gerald W. Lester
> Fredderic <put_my_n...@optusnet.com.au> writes:
>
>> On Sat, 20 May 2006 20:20:22 +0200,
>> Frank Goenninger DG1SBG <dont-e...@nomail.org> wrote:
>>
>>>> "A channel is also considered to be readable if an end of file
>>>> or error condition is present on the underlying file or
>>>> device."
>>> Yeah, I figure it's a true advantage to have the ability to
>>> read... Sorry for bothering and of course thanks for pointing out...
>>> ... to all the posters, of course... ;-)
>> Isn't [gets] supposed to throw a -1 if it hits an eof straight off?
>>
>> I usually use something like { [gets $fd line] < 0 } to decide when
>> this channel just isn't working for me anymore. Seems to work so far...
>>
>> I think [read] is supposed to do the same thing, so I've very rarely
>> actually found myself using the [eof] command at all. But yeah, you DO
>> have to check SOMEHOW...
>>
>>
>> Fredderic
>
> Frederic,
>
> thanks for the reply. Yes, I know, I do have to check, but:
>
> In case of a RS232C channel or socket channel I have the behaviour of
> fileevent saying "Currently no data there" by NOT firing. Which is
> exactly what I need.
Actually it is the identical behavior as a normal file! If you close the
socket or receive an EOF on the RS232C channel, the file event will fire and
keep firing.
This is the behavior when End Of File is reached.
>
> Though this is different for a normal file. In this case fileevent
> keeps firing. I therefore have to check which type of channel I have
> and if it's a file channel I can close it. The procedure that
> fileevent calls is sort of a generic dispatch procedure (not even in
> Tcl/Tk, but a function in Lisp called via a callback previously
> registered as new command via Tcl_CreateCommand)...
>
> Well, at least it works now for sockets and serial ports...
Please see my comments above, or you will get an error if the socket is
unexpectedly closed.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Frank Goenninger DG1SBG
> FGD> Though this is different for a normal file. In this case fileevent
> FGD> keeps firing. I therefore have to check which type of channel I have
> FGD> and if it's a file channel I can close it. The procedure that
> FGD> fileevent calls is sort of a generic dispatch procedure (not even in
> FGD> Tcl/Tk, but a function in Lisp called via a callback previously
> FGD> registered as new command via Tcl_CreateCommand)...
> FGD>
> FGD> Well, at least it works now for sockets and serial ports...
>
> You can always *generically* test for EOF: [eof <some RS232 channel>]
> will always return false, [eof <some socket channel>] will return true
> if the other end of the socket is closed, and [eof <some file channel>]
> will return true at actual EOF.
Yes, inserted this as a two-liner of code and it now just works.
Thanks again!
Frank
David Gravereaux
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]!
IOW, one must test for EOF *AFTER* [gets] or [read] in a filevent proc.
Testing for EOF before the [read] or [gets] is counterproductive for
how the channel system in Tcl works. _Only after a [read] or [gets]
does the generic side of the channel system set the eof bit that you can
test for_.
Just cause it works checking for EOF first doesn't mean that it is
guaranteed to always work that way for all channel types (core or custom).
This is part of that gray area where the division of the generic and
driver side of the channel system is ill defined.
IOW, it should not be the responsibility of the channel driver to
continually fire readable operations after an already read in EOF to the
generic layer, yet the core channel drivers do this when in fact they
shouldn't.
For example, say I'm using completion port notification on an overlapped
socket on WinNT with a custom channel driver
<http://sf.net/projects/iocpsock>. Once I retrieve the last WSARead
buffer that contains zero bytes, cause Tcl to flush my channel (call the
Tcl_DriverInputProc, thus given the generic layer EOF), _NO MORE
NOTIFICATIONS WILL ARRIVE FOR THIS SOCKET_.
Having to manufacture notifications on this socket to continually fire
readable operation until the channel is closed by someone elses
negligible script code I feel is wrong and should be the responsibility
of the generic layer, yet there is no such code in the generic side to
enable this behavior.
There, I said my peace.. :) ok, I'm done :)
Cameron Laird
David Gravereaux <davy...@pobox.com> 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]).
David Gravereaux
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...
Robert Heller
In a message on Wed, 24 May 2006 14:44:54 -0700, wrote :
DG> Cameron Laird wrote:
DG> > In article <WbydnWOJTq8...@comcast.com>,
DG> > David Gravereaux <davy...@pobox.com> wrote:
DG> >> Cameron Laird wrote:
DG> > .
DG> > .
DG> > .
DG> >>>> Yet fileevent keeps firing on the channel...
DG> >>>>
DG> >>>> I haven't set any special options on the channel.
DG> >>>>
DG> >>>> How can I prevent this behaviour?
DG> >>> .
DG> >>> .
DG> >>> .
DG> >>> It's a feature.
DG> >>>
DG> >>> The first step in processing a fileevent can/should be to test [eof $channel].
DG> >>
DG> >> Umm, sorta..
DG> >>
DG> >> If after the last read command ([gets] or [read], actually) in your
DG> >> fileevent proc had tested for eof, then you would know then.
DG> >>
DG> >> Please test for EOF *AFTER* your [read] or [gets]!
DG> > .
DG> > .
DG> > [lot more detail]
DG> > .
DG> > Davy's ABSOLUTELY right. I know better; 'fact, I've been correcting
DG> > what I wrote for most of the last decade. What I wrote is simply
DG> > wrong--I was trying to say something different, and utterly lost
DG> > track of my point.
DG> >
DG> > So, again, Davy has it: [eof] only AFTER [read] or [gets].
DG> >
DG> > The conclusion for the original poster should be that, yes, it's
DG> > important to check for [eof] (although, as others pointed out,
DG> > there are circumstances where "-1 == [gets ..." is an effective
DG> > substitute for a literal [eof]).
DG>
DG>
DG> Cameron,
DG>
DG> Sorry I pounced on you.. I didn't mean to. I have some raw nerves with
DG> regards to some incomplete aspects of the channel system; both
DG> documentation and logic.
DG>
DG> The man page for [eof] mostly implies it:
DG>
DG> "Returns 1 if an end of file condition occurred during the most recent
DG> input operation on channelId (such as gets), 0 otherwise."
DG>
DG> But doesn't actually say you must/should check for [eof] after the
DG> [read] or [gets], nor does the very long man page on the channel driver
DG> API say it is the responsibility of the channel driver to manufacture
DG> fake readable events on an unclosed and eof'd channel so a pre-checked
DG> (ill placed) [eof] test in a fileevent callback can get proper closure.
It is pretty much 'file I/O 101' to do an EOF check after reads. It
applies across all programming languages that support file I/O. From
the fileevent page:
A channel is considered to be readable if there is unread
data available on the underlying device. A channel is
also considered to be readable if there is unread data in
an input buffer, except in the special case where the most
recent attempt to read from the channel was a gets call
that could not find a complete line in the input buffer.
This feature allows a file to be read a line at a time in
nonblocking mode using events. A channel is also consid-
ered to be readable if an end of file or error condition
is present on the underlying file or device. It is impor-
tant for script to check for these conditions and handle
them appropriately; for example, if there is no special
check for end of file, an infinite loop may occur where
script reads no data, returns, and is immediately invoked
again.
So, it is in fact documented that EOF fires the readable script. And
will keep firing it until the channel is closed or the fileevent
handler it removed. It is also clearly documented that you need to
check for and handle EOF.
DG>
DG> oh god.. I seem to be entering into rant mode...
DG>
David Gravereaux
...
> So, it is in fact documented that EOF fires the readable script. And
> will keep firing it until the channel is closed or the fileevent
> handler it removed. It is also clearly documented that you need to
> check for and handle EOF.
But the channel API documentation does say who should be responsible for
invoking that event.
It should be the responsibility of the generic layer, as anyone who as
ever made I/O code knows that once you get notified for EOF on a stream
device, don't expect to ever get any other notices again.
Yet who is the responsible party to develop that event that the
fileevent callback requires?
Michael A. Cleverly
> 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.
I'm glad you raised the issue! I've been programming with Tcl for nine
years now, and I've always tested [eof] before the [read]/[gets], not
after--and never stopped to think a thing about it.
So reading your post was an "ah ha!" lights on kind of moment for me.
> oh god.. I seem to be entering into rant mode...
:-)
Michael
Fredderic
"Michael A. Cleverly" <mic...@cleverly.com> wrote:
> I'm glad you raised the issue! I've been programming with Tcl for nine
> years now, and I've always tested [eof] before the [read]/[gets], not
> after--and never stopped to think a thing about it.
I'm wondering, are there any cases where testing the result of [gets]
(with a variable name) isn't sufficient? ie. are there any cases where
[gets] will return -1 (from a file readable event), but the channel
might still be usable?
And if [read] returns data, then while the channel may be [eof], I
think it's safe to say it was valid before hand. So if [read] returns
an empty string, we should then use [eof] and what-not to determine why.
Fredderic
Donal K. Fellows
> I'm wondering, are there any cases where testing the result of [gets]
> (with a variable name) isn't sufficient? ie. are there any cases where
> [gets] will return -1 (from a file readable event), but the channel
> might still be usable?
That happens a lot if you're using non-blocking I/O. A -1 from [gets]
could indicate that it will be [fblocked] that returns 1 and not [eof].
I don't know if there is any case where [gets] returns -1 but neither
[eof] nor [fblocked] returns 1.
Donal.
Frank Goenninger DG1SBG
> 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]!
Sir! Yes, Sir! ;-)
>
> IOW, one must test for EOF *AFTER* [gets] or [read] in a filevent proc.
> Testing for EOF before the [read] or [gets] is counterproductive for
> how the channel system in Tcl works. _Only after a [read] or [gets]
> does the generic side of the channel system set the eof bit that you can
> test for_.
>
> Just cause it works checking for EOF first doesn't mean that it is
> guaranteed to always work that way for all channel types (core or custom).
>
> This is part of that gray area where the division of the generic and
> driver side of the channel system is ill defined.
>
> IOW, it should not be the responsibility of the channel driver to
> continually fire readable operations after an already read in EOF to the
> generic layer, yet the core channel drivers do this when in fact they
> shouldn't.
>
> For example, say I'm using completion port notification on an overlapped
> socket on WinNT with a custom channel driver
> <http://sf.net/projects/iocpsock>. Once I retrieve the last WSARead
> buffer that contains zero bytes, cause Tcl to flush my channel (call the
> Tcl_DriverInputProc, thus given the generic layer EOF), _NO MORE
> NOTIFICATIONS WILL ARRIVE FOR THIS SOCKET_.
>
> Having to manufacture notifications on this socket to continually fire
> readable operation until the channel is closed by someone elses
> negligible script code I feel is wrong and should be the responsibility
> of the generic layer, yet there is no such code in the generic side to
> enable this behavior.
Now, well, yes, I understand. It's only a bit complicated for me to
actually achieve this "test for EOF after GETS" for a few simple
reason:
The fileevent stuff is in Tcl, of course. I call it Tcl land as a
contrast to the Lisp land from where I call Tcl. Reading from the
channel is done in Lisp land via callback from Tcl. Now I have to jump
back into Tcl land to test for EOF.
My simple solution
proc readable {channel path} {
if [ eof $channel ] then {
eof-cb $path } else {
readable-cb $path }
}
doesn't work any more ;-) A bit more of thinking needed...
> There, I said my peace.. :) ok, I'm done :)
Wow! In-depth, detailed, clear, even for a newbie like me. Thanks!!!
Frank
Kip Rugger
There are two ideas of operating-system design in play here.
First, how is synchronization done? There are several models that
have emerged over the years:
- n-way wait (Unix select(2), MVS ecb lists)
- event lists (BSD kqueue(2), QNX mailboxes, Tcl, X event protocol)
- callbacks (Windows).
Secondly is the basic concept that flow control must be exercised by
the upstream client -- you tell the client that data can be read
rather than forcing the client to accept the actual data itself; the
client actively accepts the data when resources permit.
The fileevent behaviour is a byproduct of the early n-way wait
primitives. After the wait is satisfied, you essentially poll the
underlying files for their status. This polling is stateless in the
sense that there is no attempt to prevent previously reported status
from being reported again. That is source of the familiar
read-ready/EOF infinite loops that incorrect scripts can experience.
By contrast, the event-list primitives tend naturally not to
re-report. Indeed re-reporting would cause chaos for events such as
mouse clicks, etc. In general you can think of events as being a
vehicle for maintaining a slave copy of a master data-structure -- the
event stream reports the changes to the master so that they can be
replicated in the slave. (Of course this is an abstract
data-structure; its contents are specified but not its format.)
The case at hand is a layering problem: at what layer of the channel
implementation should the translation from n-way semantics to event
semantics occur. Because this translation is not desirable for
anything but files (and even there only for historical reasons), I
would suggest that the answer is that the caller of CreateEventSource
would be the highest layer at which it could logically occur. Or
perhaps a CreateFileeventSource service that implements the polling
behaviour.
I am now experiencing that rant feeling :)
David Gravereaux
Thanks Kip. So that's where that behavior comes from.. Now I'm
thinking about maintaining a second list of "eof, but unclosed"
sockets to query [count != 0] in the Tcl_EventSetupProc. That should
do it as I won't have to manufacture things as the polling to it Tcl
already provides.
Thanks.
David Gravereaux
<dont-e...@nomail.org> wrote:
>My simple solution
>
>proc readable {channel path} {
>if [ eof $channel ] then {
> eof-cb $path } else {
> readable-cb $path }
>}
If I'm guessing correctly.. you want something like the following.
proc readable {channel path} {
# check for async errors (sockets only, I think)
if {[string length [set err [fconfigure $channel -error]]]} {
error-cb $path $err
close $channel
return
}
# read a line from the channel
if {[catch {set line [gets $channel]} err]} {
error-cb $path $err
close $channel
return
}
if {[string length $line]} {
received-cb $path $line
}
# check for eof
if {[eof $channel]} {
eof-cb $path
close $channel
}
}
Mo Dejong wrote a cool channel helper script library that manages a
bit of the ugliness.. EasySockets?? You might consider having your
Lisp side of the fence be an easier interface than a transparent one
and let the Tcl side "do some work" than plain reporting.
Frank Goenninger DG1SBG
Yep. That's it. Cool! Thx!
>
> Mo Dejong wrote a cool channel helper script library that manages a
> bit of the ugliness.. EasySockets??
Will check.
> You might consider having your
> Lisp side of the fence be an easier interface than a transparent one
> and let the Tcl side "do some work" than plain reporting.
Hehe. Your code above does that now already... So that's solved ;-)
Thanks again!
Frank