Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

tkwait command not clear to me

187 views
Skip to first unread message

jmc

unread,
Apr 27, 2012, 2:16:49 PM4/27/12
to
Hello,

When trying to understand "tkwait variable", is it possible to say :

When the command "tkwait variable varname" is executed,

1) varname is (re)created and set to nothing (empty string ?)

2) a repeating polling begins in bakground to see if varname is set
(event loop)

3) until varname is set, the interpreter is blocked in executing
further commands in the script following "tkwait variable varname"

4) when varname is set, the associated event loop is destroyed
(polling varname stops) but varname is not destroyed, and the
interpreter continues execution following commands in the script.

Am I correct ?

Many thanks

Jean-Marie

Donal K. Fellows

unread,
Apr 28, 2012, 2:48:56 AM4/28/12
to
On 27/04/2012 19:16, jmc wrote:
> When trying to understand "tkwait variable", is it possible to say :

It's exactly the same as [vwait varname].

> When the command "tkwait variable varname" is executed,
>
> 1) varname is (re)created and set to nothing (empty string ?)

It's not created, though its variable record *is* so that a trace can be
set on it. What is set is a write trace (maybe an unset trace too; I'd
have to check the code to be sure).

> 2) a repeating polling begins in bakground to see if varname is set
> (event loop)

The event loop is actually a little more efficient than that, but yes.
It's effectively like this:

set ::varWasSet 0
trace add variable varname write {set ::varWasSet 1; # ignore rest}
while {!$::varWasSet} {
update
}

Except that it's done in C so it doesn't need global variables and can
use the options to the event loop code that make it wait for events.

> 3) until varname is set, the interpreter is blocked in executing
> further commands in the script following "tkwait variable varname"

Yes. It _waits_.

> 4) when varname is set, the associated event loop is destroyed
> (polling varname stops) but varname is not destroyed, and the
> interpreter continues execution following commands in the script.

Yes (except that the event loop isn't really destroyed; it's a loop that
calls into the event loop; let's be precisely correct). We most
certainly don't bother to unset the variable; you could always add that
yourself in your script if desired.

The other types of [tkwait] (visibility and window) are just the same,
except they have different triggers (<Visibility> and <Destroy> events,
respectively). They're not used nearly so much now, especially true for
[tkwait visibility] as that's not portable (not all platforms produce
the relevant event analog).

A consequence of this is that running [tkwait] (or [vwait]) in an event
can easily end up creating a concealed nesting of event loops, which
will clog up the stack and cause much grief. This is discussed on the
Wiki at http://wiki.tcl.tk/1255 (it mostly talks about [update], but as
we know from above, the waits are really wrappers around the same
functionality, and have the same problems).

Donal.

jmc

unread,
Apr 30, 2012, 3:07:03 AM4/30/12
to
On 28 avr, 08:48, "Donal K. Fellows"
> Wiki athttp://wiki.tcl.tk/1255(it mostly talks about [update], but as
> we know from above, the waits are really wrappers around the same
> functionality, and have the same problems).
>
> Donal.

Thanks for the precisions Donal. I read http://wiki.tcl.tk/1255 too .
Things are now clearer to me : thanks again

Jean-Marie

Donal K. Fellows

unread,
Apr 30, 2012, 4:14:25 AM4/30/12
to
On 30/04/2012 08:07, jmc wrote:
> Thanks for the precisions Donal. I read http://wiki.tcl.tk/1255 too .
> Things are now clearer to me : thanks again

Do feel free to help us improve our documentation and wiki. The main
issue we have is that we already know what's going on too well, so we
don't understand what the problems are. Only by having people with less
experience with Tcl and Tk (such as yourself) doing the reviewing can we
make things better.

To get improvements in the main docs, email me or file a bug report on
SourceForge (which probably comes back to me anyway ;-)). To improve the
wiki, just click the edit link on the page (sidebar or footer).

Donal.

jmc

unread,
Apr 30, 2012, 9:49:07 AM4/30/12
to
On 30 avr, 10:14, "Donal K. Fellows"
<donal.k.fell...@manchester.ac.uk> wrote:
> On 30/04/2012 08:07, jmc wrote:
>
> > Thanks for the precisions Donal. I readhttp://wiki.tcl.tk/1255too .
> > Things are now clearer to me : thanks again
>
> Do feel free to help us improve our documentation and wiki. The main
> issue we have is that we already know what's going on too well, so we
> don't understand what the problems are. Only by having people with less
> experience with Tcl and Tk (such as yourself) doing the reviewing can we
> make things better.
>
> To get improvements in the main docs, email me or file a bug report on
> SourceForge (which probably comes back to me anyway ;-)). To improve the
> wiki, just click the edit link on the page (sidebar or footer).
>
> Donal.

Thanks Donal, I appreciate your offer. Actually, I hesitated to put my
question on the wiki (as I understand it may help other non experts in
tcl). Next time, if my questions aren't too narrow, I will write them
on the wiki, thanks for the proposition.

A nice (to me) general feature I suggest to improve the doc should be,
when possible, to give the reference (in the "SEE ALSO" section ?) of
the TIP(s) directly involved for the command explained, giving this
way the origin of the feature.
Whis this reference, if the need to go deeper in the details occurs,
you don't have to search in the index of TIPs to see if eventualy
there is something related to the command of interest. (From my point
of vue, appart the C langage I don't know, I generaly found the TIPs
very easy to read and to follow (and instructive too)).

Jean-marie




0 new messages