Re: Event loop and http::geturl

On 6/26/2025 12:09 PM, Jonathan Kelly wrote:

On 27/6/25 03:08, Rich wrote:

et99 <et99@rocketship1.me> wrote:

On 6/25/2025 2:32 PM, Rich wrote:

Jonathan Kelly <jonkelly@fastmail.fm> wrote:

proc queue {} {
    set ::input [open "|cat test.txt" r]
    fconfigure $::input -blocking 0 -buffering line
    fileevent $::input readable [list check $::input]
}

>
Curious why you are opening a pipe to cat, having cat read and print
the contents, and then consuming that, when you can just open
text.txt directly:
>
set ::input [open test.txt r]
>
And achieve the same result.

>
I was also curious about this.  But I'm also wondering why this is
even event driven at all?  Why not simply, in pseudo code:

>
My guess: the above was OP's "test case" code.  The real code is
reading an Apache log file as Apache logs to the file, so 'event
driven' in that senario does make some sense.
>

What Rich said. Before I realised geturl is *always* asynchronous, I had read the man for geturl where it said geturl "blocked". I needed to simplify my program as a test case to prove something was broken. Turned out, the problem was my understanding, though I still think the manual page is mis-leading. The relevant
 "Note: The event queue is even used without the -command option. As a side effect, arbitrary commands may be processed while http::geturl is running."
 is in the general description at the top, and I had just been reading the geturl function description.

I wonder, if you are reading a file that is being written from another process, sort of like a "tail" program, doesn't tcl's [fileevent <channel> readable <script>] trigger constantly? Isn't this in effect a tight polling loop?
The manual says:
"A channel is also considered to be readable if an end of file or error condition is present on the underlying file or device. It is important 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."
To avoid this problem, one is normally supposed to close the file or remove the read handler. I've never written a log handler like this one, so I'm not sure what the correct approach would be.