Event Loop

[Eric]

Is there any way a script can tell whether an event loop already exists?

TIA

Eric
--
ms fnd in a lbry

[Hypnotoad]

I'm not sure what you are asking. From Tcl's perspective, the event loop always exists because it's part of the core. If you are looking to maintain some sort of cooperative multitasking arrangement, you might try "cron" in tcllib. It allows you to build a virtual process that can be started, stopped, invoked periodically, or triggered to wake at some point in the future.

http://core.tcl.tk/tcllib/doc/trunk/embedded/www/tcllib/files/modules/cron/cron.html

--Sean "The Hypnotoad" Woods

[Ashok]

I presume you mean whether the event loop is already running and
dispatching events. The answer is no afaik.

/Ashok

[Eric]

On 2017-09-15, Ashok <pal...@yahoo.com> wrote:
> On 9/15/2017 1:36 AM, Eric wrote:
>> Is there any way a script can tell whether an event loop already exists?
>

> I presume you mean whether the event loop is already running and
> dispatching events. The answer is no afaik.
>

Indeed I do.

[Eric]

On 2017-09-15, Hypnotoad <yo...@etoyoc.com> wrote:
> On Thursday, September 14, 2017 at 4:10:10 PM UTC-4, Eric wrote:
>> Is there any way a script can tell whether an event loop already exists?
>>
>

> I'm not sure what you are asking. From Tcl's perspective, the event
> loop always exists because it's part of the core.

But it might not be active, which is what I need to know. Badly worded
question I guess.

> If you are looking to maintain some sort of cooperative multitasking
> arrangement, you might try "cron" in tcllib. It allows you to build
> a virtual process that can be started, stopped, invoked periodically,
> or triggered to wake at some point in the future.
>
> http://core.tcl.tk/tcllib/doc/trunk/embedded/www/tcllib/files/modules/cron/cron.html
>

Thanks, I never spotted that one before. Another one for the "I really
must find time to look at ..." list :-) .

It does seem to be an example of my problem in that it's a package that
needs the event loop and uses vwait to get it. But what happens if
its caller has already done a vwait , or activated the event loop some
other way?

[Gerald Lester]

Why do you want to know? What is the problem you are attempting solve?


--
+----------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald...@kng-consulting.net |
+----------------------------------------------------------------------+

[Eric]

On 2017-09-15, Gerald Lester <Gerald...@KnG-Consulting.net> wrote:
> On 09/15/2017 09:49 AM, Eric wrote:
>> On 2017-09-15, Ashok <pal...@yahoo.com> wrote:
>>> On 9/15/2017 1:36 AM, Eric wrote:
>>>> Is there any way a script can tell whether an event loop already exists?
>>>
>>> I presume you mean whether the event loop is already running and
>>> dispatching events. The answer is no afaik.
>>>
>> Indeed I do.
>
> Why do you want to know? What is the problem you are attempting solve?
>

See my other responses. But in essence, I need to use vwait but it
would be a bad idea if some other package being used has already done
it.

[Gerald Lester]

Sorry, post don't always arrive in the same order at every box.

[Robert Heller]

If some other package has done a vwait, then that would be the end of loading
code and your main program (with its vwait) will never run. The only other
way the event loop would be entered is if someone did a 'package require Tk'
(and you can test for that:

if {![catch package present Tk]} {
vwait forever
}
)

Typically to enter the event loop in a *non* Tk program, you would have

vwait forever

as the very last thing in the main script. This statement is never going to
return to the command level, unless someone sets the 'forever' variable (which
would be a really dumb thing to do). Not that there is anything special
about the variable name 'forever' -- you can use any name you like, but the
name forever is the one 'traditionally' used for just this purpose. And it
nicely documents what is going on here.

Basically, there really isn't any real need to test for the event loop already
existing, outside of testing for the Tk package.

>
> Eric

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
hel...@deepsoft.com -- Webhosting Services

[Eric]

OK then,

* my package expects to be called by somebody else's main script
(possibly as yet unwritten)
* that script may or may not have Tk, and may or may not contain
a vwait
* that script will have to load my package before it does a vwait
* my package would not do a vwait when loaded, but when some procedure
in it is called
* the main script may call that procedure in a event, or not

[Robert Heller]

Is your package calling vwait to actually wait for a specific variable (say
a timeout flag)?

There are two uses of "vwait". One is to just wait on a variable (its
original, main purpose). vwait is *also* "used" to force entry into the event
loop, when it *might* not be entered "natrually". This latter case relates to
plain Tcl programs that might be using event driven features (usually
fileevent, but also server sockets and possibly other things, like after
events). If your package is using vwait to actually wait on a variable, there
is no need to "test" for the event loop. If your package is doing something
with fileevents, server sockets, or using "after" to periodically call a
procedure, then you might need the *main* program to include a "vwait forever"
statement at the end of its main code (unless it has done a package require
Tkat some point).