Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: et99 <et99@rocketship1.me>
Newsgroups: comp.lang.tcl
Subject: Re: Event loop and http::geturl
Date: Thu, 26 Jun 2025 14:02:34 -0700
Organization: A noiseless patient Spider
Lines: 42
Message-ID: <103kcha$3ll1r$1@dont-email.me>
References: <103cf0h$1glgk$1@dont-email.me> <103d93c$1q263$1@dont-email.me>
 <103dm05$1svqt$1@dont-email.me> <103ffab$2b701$1@dont-email.me>
 <103g70o$2k78v$1@dont-email.me> <103gdlo$2lnei$1@dont-email.me>
 <103hem3$2ua8s$1@dont-email.me> <103hptq$30q4s$1@dont-email.me>
 <103i951$33lgp$1@dont-email.me> <103juqc$3imgb$1@dont-email.me>
 <103k5sj$3kaj3$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 26 Jun 2025 23:02:35 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="52930802acceb1f9cc050d3ec98e1deb";
	logging-data="3855419"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/ANgAyN/gXpbo+2rJbnF49"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:g5U0w2sTt4YtcLNDBmz2++awOCY=
In-Reply-To: <103k5sj$3kaj3$1@dont-email.me>
Content-Language: en-US

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.