Hello,
preparing an Event introduction, I started to write down and structure
my knowledge about the module. Here are a few questions and suggestions
that came up (the numbers are only there to structure the questions):
1) Event manages watcher objects internally. That's why there is no
urgent need to manage them yourself. On the other hand, if you want to
do this, it is possible. As a side effect of this, one can have a
watcher object that is already terminated by cancel(). Now, the doc
says:
"If an attempt is made to use $watcher after calling cancel() then an
exception will be thrown."
Is this still true? For example, I could do the following without
causing an exception:
$w=Event->io;
$w->cancel;
print $w->prio;
May be this is not the usage mentioned in the quoted doc text?
Further more, I could call "$w->again()" to reactivate the watcher and
it WORKS after that (contrary to the docs).
In the example above, it seems to me that calling $w->cancel() became
synonym to calling $w->stop(), am I right?
Further more, one can check if a watcher was cancelled - by calling
is_active(). So I suggest to note this in the doc as well, e.g.:
- snip --
=item $watcher->is_active
Reports whether the C<$watcher> has been started. The return value
depends on the least recent call of certain methods as follows:
I<start()>, I<again()>: true,
I<cancel()>, I<stop()>: false.
The value of the I<suspend> attribute does not affect the methods reply.
- snip --
2) The doc says: "MOST constructors return already active watchers." And
at another place: "When created, watcher objects ARE "started" and ARE
waiting for events." It is not completely clear if there are watchers
which are NOT active immediately after construction. If so, I suggest to
include a list of them.
3) loop() only runs if there is an (active?) watcher, it immediately
terminates if not. But because it is possible to construct watchers
without all necessary data which are active nevertheless, loop() RUNS
the following way:
use Event;
Event->io;
Event::loop;
This is a complete, valid script. I think this should be prevented.
(This script blocks my perl debugger. At least.)
More, is it prevented that someone suspends all his watchers and ends up
with such a dead loop, too?
4) "All watchers support at least the following attributes: cb, hits,
prio, desc, repeat, debug, and reentrant." As I understood, the new data
attribute is a basic one, but is not mentioned here. And what about
async, max_cb_tm, nice and running?
5) "got is available in the callback of watchers with poll.", but got is
not documented for var watchers which own poll as well.
6) var watchers have a poll attribute which is described with valid
values r, w, e and t. Now, this is clear for io watchers, but what does
"e" mean for var watchers? And, because they have no timeout attribute,
"t"?
7) The hard attribute is documented for timers. This is clear. It is
documented for io watchers as well - I suppose it influences the timeout
calculation there? If so, it should be an attribute of all watchers
which have a timeout setting - but inactivity has not.
8) Could you provide a list of which attribute settings are mandatory
for the certain watcher types?
9) If I install a watcher and delay the call of loop(), what about
events arriving in the meantime?
Greetings
Jochen
