Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Rich Newsgroups: comp.lang.tcl Subject: Re: Event loop and http::geturl Date: Tue, 24 Jun 2025 04:21:01 -0000 (UTC) Organization: A noiseless patient Spider Lines: 38 Message-ID: <103d93c$1q263$1@dont-email.me> References: <103cf0h$1glgk$1@dont-email.me> Injection-Date: Tue, 24 Jun 2025 06:21:01 +0200 (CEST) Injection-Info: dont-email.me; posting-host="49cadd6aad52ccb5031efc129f606c64"; logging-data="1902787"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/2C3PNOk19mCtqF+S2m2jC" User-Agent: tin/2.6.1-20211226 ("Convalmore") (Linux/5.15.139 (x86_64)) Cancel-Lock: sha1:gcTgu5oPN0KQb/xgN70fqfjzyk4= Jonathan Kelly wrote: > So, it looks like ::http::geturl is operating asynchronously, despite my > program NOT using -command. It does. It is documented as such: man n http: 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. The code snippets below are from http-2.9.5.tm which was distributed (at least) with 8.6.12: Buried deep in http::geturl: # geturl does EVERYTHING asynchronously, so if the user # calls it synchronously, we just do a wait here. http::wait $token And the implementation of http::wait is: proc http::wait {token} { variable $token upvar 0 $token state if {![info exists state(status)] || $state(status) eq ""} { # We must wait on the original variable name, not the upvar alias vwait ${token}(status) } return [status $token] } And the 'vwait' there reenters the event loop and allows other events to be processed.