On Mon, Jan 31, 2000 at 05:26:27PM +0100, [EMAIL PROTECTED] wrote:
> > > 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.:
> >
> > Do you want an is_cancelled() method? I could add that, but it didn't
> > seem important.
>
> This was my first thought. Then I discovered that the already existing method
> is_active() changes its behaviour and could be used exactly this way. But now that
> you fixed this, I really suggest is_cancelled(), at least for consistency (there are
> other is_state_entered() methods as well).
>
> My point here is an intuitive interface, and I think this is important. I'm going to
> explain Event to some people and it sounds better to say "if you manage watcher
> objects yourself, you should always take care not to use them after they are
> cancelled, which could be checked by the is_cancelled() method" - compared with
> this: "you can manage watchers yourself as well, but don't be surprised to see
> exceptions if you use one of them after its cancellation".
That's pretty convincing. It's added. :-)
> > > 6) var watchers have a poll attribute which is described with valid
> > > values r, w, e and t.
> >
> > Where do you see this?
>
> In the description of the poll attribute.
>
> > FYI, var watchers only respect the R & W flags.
>
> That is what one would expect, of course. The point is that "poll" is described in
> general, possibly when it was used only in io watchers, but that parts of this
> description are valid only for io watchers. I would suggest to note this.
OK, I'll add a comment. Thanks.
> > Timeout is not a problem to add, but no one has requested it yet.
>
> So don't I. My point was that it is documented as a valid "poll" value in general,
> why it is NOT valid if "poll" is an var watcher attribute.
>
> But really ... why should the timeout attribute NOT become generally available? This
> would simplify the interface, wouldn't it?
It's more code to write. I prefer not to add features unless they are
obvious or requested. Maybe this fits into the category of "obvious?"
> > > 8) Could you provide a list of which attribute settings are mandatory
> > > for the certain watcher types?
>
> The reason to ask for these details is, as mentioned before, the wish for a clear
> interface. Of course Event users are developers and can figure these things out by
> trial and error at least, but ... hm!
>
> Hm again. Just a thought: IF there is already such an (even unstructured) list,
> could you please send it to me? I could try to include these informations to the
> intro article, and hopefully the result will be tables which I could send back to
> you if you wish.
idle: (always OK)
io: timeout or valid file descriptor
signal: valid signal
timer: a timeout; if repeatable then interval must be positive
var: poll & var setup; var must not be read-only (e.g. $1); a given
variable can only be watched by one watcher
> > > 9) If I install a watcher and delay the call of loop(), what about
> > > events arriving in the meantime?
>
> Oh! Why? Is there an answer on UNIX?
Let's see...
idle: works as usual
io: imagine what happens if you ^Z (suspend) a telnet session;
stdin/stdout buffers fill up until pipes break
signal: no signals will be lost, but they will be clumped into a single
event
timer: time elapses whether in loop() or not; expired timers will be
serviced as soon as loop() can schedule them
var: queues events as usual but the events cannot be dispatched until
loop() is entered
--
"Never ascribe to malice that which can be explained by stupidity."
via, but not speaking for Deutsche Bank
