Sujet : Re: Event loop and http::geturl
De : jonkelly (at) *nospam* fastmail.fm (Jonathan Kelly)
Groupes : comp.lang.tclDate : 25. Jun 2025, 19:20:51
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <103hem3$2ua8s$1@dont-email.me>
References : 1 2 3 4 5 6
User-Agent : Mozilla Thunderbird
On 25/6/25 18:57, et99 wrote:
On 6/25/2025 12:03 AM, et99 wrote:
On 6/24/2025 5:19 PM, et99 wrote:
>
... snip ....
It has just now occurred to me that you are running your [test1] proc as a fileevent script. Read the vwait manual under the section:
"NESTED VWAITS BY EXAMPLE"
I use geturl synchronously with no issues. But I do a single url request and wait for it, in the main line code - NOT inside an event.
The code I presented in the prior posting is how you could use -command and get a synchronous result. It is only really useful if you were going to do something between the geturl and the wait for it to be done. Otherwise, you could just call it synchronously - but NOT inside an event, if another fileevent might trigger before the first one is done.
As you will see with the example in the manual, things have to unwind, so if your fileevents occur fast enough, they may have triggered before earlier geturl calls will have had time to unwind. The event loop works like a stack.
That's why the timestamps are output in reverse order of when the geturl was called.
I'm not sure exactly what you want to accomplish. But is sounds to me like you need to do some queuing or co-routines. I have code I wrote that does single queue with 1 or more servers using threads. I sometimes use it for just a single server to get my own queuing of events.
Unfortunately, I can't use it with tcl 9.0 because of a race condition bug with respect to package requires inside threads that has been ticketed but not yet looked into.
(sorry for so many postings :)
-e
Thanks for looking at it. Yes, I had to do a queue - my case is exactly like the test1 code I posted ... the events that end up triggering the geturl come in quicker than the geturl can process, and the geturl re-enters the event loop under the hood enabling more geturl-triggering-events to queue up in the event queue(?) - eventually enough to crash something. Anyway I did this ...
----------------
set ::test_busy 0
set ::test_queue {}
proc queue {} {
set ::input [open "|cat test.txt" r]
fconfigure $::input -blocking 0 -buffering line
fileevent $::input readable [list check $::input]
}
proc check {chan} {
if {[gets $chan line] >= 0} {
queue_test $line
}
proc queue_test {n} {
set task [list test1 $n]
lappend ::test_queue $task
maybe_run_test
}
proc maybe_run_test {} {
if {$::test_busy} return
if {[llength $::test_queue] == 0} return
set ::test_busy 1
# get first in queue
set next [lindex $::test_queue 0]
# remove first from queue
set ::test_queue [lrange $::test_queue 1 end]
# run first
uplevel #0 $next
set ::test_busy 0
maybe_run_test
}
----------------