Question on vwait
Helmut Giese
the statement
vwait stop
will enter the event loop (if it isn't already running) and wait until
somebody else sets 'stop'.
My question now is: Once the 'vwait' is satisfied and returns, does
the event loop stop (and needs to be re-started by another vwait), or
does it continue to run (and feed e.g. file events).
Any insight will be greatly appreciated.
Best regards
Helmut Giese
Schelte Bron
> My question now is: Once the 'vwait' is satisfied and returns,
> does the event loop stop (and needs to be re-started by another
> vwait), or does it continue to run (and feed e.g. file events).
There is nothing special about the vwait command. Once it has done
its job, processing continues as usual. So, if there's another
source that causes the event loop to run, it wil run. If not, it
stops.
Example: Take this script:
after 10000 {set stop Stop!}
vwait stop
puts $stop
If you run this in a regular tclsh, which doesn't provide its own
event loop, then after 10 seconds the program prints Stop! and then
is done, so it exits.
However, if you run the same script in wish, which does create its
own event loop, then after 10 seconds again the program will print
Stop! after which the wish event loop will continue to process any
events that may occur.
Also when you nest vwait calls, when the innermost vwait returns,
events will continue to be processed until the outermost vwait has
been triggered too.
Schelte.
--
set Reply-To [string map {nospam schelte} $header(From)]
Clemens Hintze
> Hello out there,
Hello Helmut,
> the statement
> vwait stop
> will enter the event loop (if it isn't already running) and wait until
> somebody else sets 'stop'.
Partly yes. I prefer to see it like: every vwait enter its own eventloop
regardless if there is one running, or not. This has consequences if you
have nested vwait, that I would regard as nested eventloops (whereas I
do not know, if eventloops really nest, but I handle them as they would
do).
Suppose you have two eventloops pending whereas the inner one vwait for
INNER and the outer one for setting of OUTER.
If you now set variabel OUTER, nothing will happen as the inner
eventloop's exit criteria was not fulfilled yet. So the flow remains in
the inner eventloop.
Now if you set variable INNER, the vwait INNER returns thereby leaving
its established eventloop. But the eventloop started by vwait OUTER is
still running without recognizing, that you perhaps already did setting
variable OUTER before. But if you now set OUTER, the vwait will also
return thereby quitting its eventloop.
Now as no any eventloop is running and events will not be handled until
another vwait will enter the eventloop again.
HTH,
Clemens.
--
Clemens Hintze mailto: c.hintze (at) gmx.net
Donald Arseneau
> If you now set variabel OUTER, nothing will happen as the inner
> eventloop's exit criteria was not fulfilled yet. So the flow remains in
> the inner eventloop.
Nothing will happen yet...
> Now if you set variable INNER, the vwait INNER returns thereby leaving
> its established eventloop. But the eventloop started by vwait OUTER is
> still running without recognizing, that you perhaps already did setting
> variable OUTER before.
That is wrong. The OUTER event handler will run as soon as the INNER
has returned. It does know that you set the variable while it was blocked.
--
Donald Arseneau as...@triumf.ca
Helmut Giese
>Helmut Giese wrote:
>> My question now is: Once the 'vwait' is satisfied and returns,
>> does the event loop stop (and needs to be re-started by another
>> vwait), or does it continue to run (and feed e.g. file events).
>
>There is nothing special about the vwait command. Once it has done
>its job, processing continues as usual.
weird behaviour with an extension I wrote - see 'Event woes' - and
this question was sort of an aside.
Thanks and best regards
Helmut Giese
Helmut Giese
thanks for your explanation. As you will have noticed in 'Event woes',
my real problem is something else - the vwait aspect is simply a
symptom.
Best regards
Helmut Giese
Clemens Hintze
> Clemens Hintze <c...@disks.qiao.in-berlin.de> writes:
(...)
>> Now if you set variable INNER, the vwait INNER returns thereby leaving
>> its established eventloop. But the eventloop started by vwait OUTER is
>> still running without recognizing, that you perhaps already did setting
>> variable OUTER before.
>
> That is wrong. The OUTER event handler will run as soon as the INNER
> has returned. It does know that you set the variable while it was blocked.
Yes, you are right! I have misinterpreted some strange behavior in my
application that seemed to block by not recognizing that some variable
was already set via an event came in via comm message.
That happened only if some nesting of eventloops occured. Now since I
have flatten the eventloop, it did never occur again. My explanation
attempt above did explain the strange behavior so that I did assume,
that this was the case.
But after you corrected me, I tried again a small application and saw,
that I was wrong! Now I still do not know, why my application using
nested eventloops failed under some circumstances :-(
Doesn't matter, as one should try to avoid them anyway :-)
Thanks for clarification,