Grupos de Google ya no admite nuevas publicaciones ni suscripciones de Usenet. El contenido anterior sigue siendo visible.

startEventLoop

Visto 48 veces
Saltar al primer mensaje no leído

Cecil Westerhof

no leída,
7 jun 2018, 11:59:057/6/18
a
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

no leída,
7 jun 2018, 13:11:517/6/18
a
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

no leída,
7 jun 2018, 13:59:047/6/18
a
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

no leída,
7 jun 2018, 16:13:507/6/18
a
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

no leída,
7 jun 2018, 17:26:397/6/18
a
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

no leída,
11 jun 2018, 11:37:3211/6/18
a
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

no leída,
11 jun 2018, 13:31:2511/6/18
a
* 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

no leída,
11 jun 2018, 13:39:2411/6/18
a
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 mensajes nuevos