Re: repeat(0)/repeat(1) and stop()/start()
[email protected] (Joshua N Pritikin)
| Newsgroups | perl.loop |
|---|---|
| Message-ID | <[email protected]> |
On Mon, Feb 21, 2000 at 11:24:45AM +0100, [email protected] wrote: > I was talking with another programmer about Event, and we came to a > point where he asked me if repeat(0)/repeat(1) is synonym to > stop()/start(). This seems to be underdocumented, so I wrote this hack > [... snip ...] > > This script implements a one shot watcher which is activated and > deactivated by several timers via repeat(). Some thoughts: > > Until this question, I expected that a one shot watcher automatically > becomes INACTIVE after callback invokation. But if you run the script, > you can see that the repeat() method surprisingly does not influence the > activity flag EVEN AFTER CALLBACK INVOKATION. Try the attached script. If you type something while REPEAT=1 then the watcher remains active. However, if you type something while REPEAT=0 then the watcher changes to inactive, permanently. I think this is correct...? > So we have an active > watcher behaving like an inactive one after callback invokation. If you > observe such a watcher by ProcessTop, it is reported as "zombie", but as > the programmer proposed, different to usual zombies it can be reanimated > by a call of repeat(1). The watcher can be reanimated by calling start() or again(). Try typing start or again in the test script. > So, to sum it up, thanks to this proposal I discovered this unexpected > usage of the repeat() method. My question is if it is necessary to > implement it that hidden way - there seems to exist an additional > internal flag. Wouldn't it make the interface clearer if repeat(0) would > enforce a watcher to become simply INACTIVE after callback invokation? > This would allow to reuse the watcher later on by simply calling again() > - for just another one shot activity (the repeat attribute would remain > unchanged). repeat(1), on the other hand, should just set the attribute > in my opinion, as well as other attribute methods do. It should not > reactivate the watcher. I don't understand. > Just another point. The script above runs well on Solaris, but on Linux > it behaves differently. If you enter something in STDIN on Linux while > the script reports to be "INACTIVE", the screen is filled by a message > that an event arrived for an "!ACTIVE" watcher. This message is > displayed again and again, and it seems the loop is out of control then, > no callback is invoked after this. Can you post the output? This sounds like a real bug... -- "May the best description of competition prevail." via, but not speaking for Deutsche Bank
repeat.t
(application/x-troff, 600 B) - not displayed