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

startEventLoop

48 views
Skip to first unread message

Cecil Westerhof

unread,
Jun 7, 2018, 11:59:05 AM6/7/18
to
I often want an event loop that runs forever and terminates when there
is an error. for this I created the proc startEventLoop.

You can find it here:
http://wiki.tcl.tk/55367

--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Rich

unread,
Jun 7, 2018, 1:11:51 PM6/7/18
to
Cecil Westerhof <Ce...@decebal.nl> wrote:
> I often want an event loop that runs forever and terminates when there
> is an error. for this I created the proc startEventLoop.
>
> You can find it here:
> http://wiki.tcl.tk/55367

One small tip, if you perchance ever wanted to exit the event loop (by
exiting the vwait due to setting the variable) then you might consider
making the "forever" variable inside the proc a global.

As it is a local now, there is no way to set it (because it is proc
local) after you do get into the event loop.

Cecil Westerhof

unread,
Jun 7, 2018, 1:59:04 PM6/7/18
to
Well, the idea is that it runs forever. ;-)
But I could at a parameter that while the default is False would make
the variable global when the parameter is True.

Rich

unread,
Jun 7, 2018, 4:13:50 PM6/7/18
to
Cecil Westerhof <Ce...@decebal.nl> wrote:
> Rich <ri...@example.invalid> writes:
>
>> Cecil Westerhof <Ce...@decebal.nl> wrote:
>>> I often want an event loop that runs forever and terminates when there
>>> is an error. for this I created the proc startEventLoop.
>>>
>>> You can find it here:
>>> http://wiki.tcl.tk/55367
>>
>> One small tip, if you perchance ever wanted to exit the event loop (by
>> exiting the vwait due to setting the variable) then you might consider
>> making the "forever" variable inside the proc a global.
>>
>> As it is a local now, there is no way to set it (because it is proc
>> local) after you do get into the event loop.
>
> Well, the idea is that it runs forever. ;-)

Normally, yes. But then, one day, you end up needing to do something
after exiting the event loop cleanly.....

> But I could at a parameter that while the default is False would make
> the variable global when the parameter is True.

Other than hiding the variable there is no performance difference,
since there are at most two accesses to the variable during the whole
runtime (the vwait setup, and a 'set' at some point when a clean exit
is desired (if it is ever desired...).

Robert Heller

unread,
Jun 7, 2018, 5:26:39 PM6/7/18
to
At Thu, 7 Jun 2018 20:13:47 -0000 (UTC) Rich <ri...@example.invalid> wrote:

>
> Cecil Westerhof <Ce...@decebal.nl> wrote:
> > Rich <ri...@example.invalid> writes:
> >
> >> Cecil Westerhof <Ce...@decebal.nl> wrote:
> >>> I often want an event loop that runs forever and terminates when there
> >>> is an error. for this I created the proc startEventLoop.
> >>>
> >>> You can find it here:
> >>> http://wiki.tcl.tk/55367
> >>
> >> One small tip, if you perchance ever wanted to exit the event loop (by
> >> exiting the vwait due to setting the variable) then you might consider
> >> making the "forever" variable inside the proc a global.
> >>
> >> As it is a local now, there is no way to set it (because it is proc
> >> local) after you do get into the event loop.
> >
> > Well, the idea is that it runs forever. ;-)
>
> Normally, yes. But then, one day, you end up needing to do something
> after exiting the event loop cleanly.....

Normally, all you will ever do after exiting the event loop is exit. If you
need to do something else just before exiting, you could just include that in
the exit code:

proc myCleanExit {} {
# clean things up (close files, close sockets, delete temp files, whatever)
::exit
}

Then in your code (somewhere deep under the event loop possibly) you call
myCleanExit.

>
> > But I could at a parameter that while the default is False would make
> > the variable global when the parameter is True.
>
> Other than hiding the variable there is no performance difference,
> since there are at most two accesses to the variable during the whole
> runtime (the vwait setup, and a 'set' at some point when a clean exit
> is desired (if it is ever desired...).
>

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

Gerhard Reithofer

unread,
Jun 11, 2018, 11:37:32 AM6/11/18
to
On Thu, 7 Jun 2018, Robert Heller wrote:

> At Thu, 7 Jun 2018 20:13:47 -0000 (UTC) Rich <ri...@example.invalid> wrote:
>
> >
> > Cecil Westerhof <Ce...@decebal.nl> wrote:
> > > Rich <ri...@example.invalid> writes:

...

> Normally, all you will ever do after exiting the event loop is exit. If you
> need to do something else just before exiting, you could just include that in
> the exit code:
>
> proc myCleanExit {} {
> # clean things up (close files, close sockets, delete temp files, whatever)
> ::exit
> }

I would even vote for an exit-callback.

proc startEventLoop {{exitproc {}} {bgerrorIsFatal True}} {
if {${bgerrorIsFatal}} {
interp bgerror {} fatal
}
vwait forever
if {$exitproc ne ""} {
eval {*}$exitproc
}
::exit
}

Usage example:
startEventLoop [list SpaceMouse::sm_close]

An intended "close" can be triggered by
set ::forever 0
because then vwait parameter "forever" IS a global variable!

BTW: Many, many thanks to Cecil and the other TCLers, that thay make my
work. I'm currently working on a "driver" for my ancient space mouse 3d
controller and it was one of my next tasks to write such a procedure.
Task finished :-) :-) :-)

--
Gerhard Reithofer - Techn. EDV Reithofer - http://www.tech-edv.co.at

Ralf Fassel

unread,
Jun 11, 2018, 1:31:25 PM6/11/18
to
* Gerhard Reithofer <gerhard....@tech-edv.co.at>
| eval {*}$exitproc

Isn't that "doppelt gemoppelt"?

Either (preferably)
{*}$exitproc
OR
eval $exitproc
should be enough, but not both, since that has the danger of
double-eval-errors.

My Eur 0.01
R'

Gerhard Reithofer

unread,
Jun 11, 2018, 1:39:24 PM6/11/18
to
Hi Ralf,

On Mon, 11 Jun 2018, Ralf Fassel wrote:

> * Gerhard Reithofer <gerhard....@tech-edv.co.at>
> | eval {*}$exitproc
>
> Isn't that "doppelt gemoppelt"?

definitely yes ;-) ;-);-)

> Either (preferably)
> {*}$exitproc
> OR
> eval $exitproc
> should be enough, but not both, since that has the danger of
> double-eval-errors.

THX,
Gerhard
0 new messages