> > (a) Create a new session for each incoming request. Hope not.
>
> Why is this so bad?
Because I would be creating an unlimited number of sessions to
serve maybe just one client session. That would in turn require
the kernel to send all kinds of events like _start, _stop,
_garbage_collect, do reference counting, etc. for each of those
sessions. And as far as handling alarms, the kernel would still
have to go through the list of alarms to remove just one of
them. In short, I am not doing that, I'd rather go with the (b)
solution.
> > (c) Have a way to remove a single pending alarm. For that some
> > kind of alarm ID would be needed, along with an alarm_remove
> > kernel method that would take an alarm ID...
>
> This is rather trivially implmented by a module so I see no real
> reason for it to go into Kernel.pm
>
> Why not write PoCo::Cron that does it, a nifty use of weakrefs and
> alarm objects would provide a neat and clean interface to this.
I don't see how creating a separate module or a component could help
solve the problem, unless we are talking about the (a) solution
again. The component would still have the problem of removing just
one alarm out of the many alarms it handles in parallel.
> > # code goes to Kernel.pm
> > ...
>
> That looks possible super slow for a large amount of alarms.
I must admit I don't know much about Perl internals, so I can't
make a good argument as to why it would or would not be super slow,
but right now I don't see any way to make it much more efficient.
To kill an alarm, you have to go through the list of alarms, as
they are ordered by delivery time, not by ID.
Kirill
