01-05-26 22.49, skrev Kirill p� [EMAIL PROTECTED] f�ljande:
>>> (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.
uhm, oh I see one incoming request, multiple requests per client, OTOH poe
is written to handle many sessions so that is what the core is optimized
for, have you benchmarked this 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
>
>
No you don't an implmentation where you hold a reference to the timer object
can be implmented so when you release the timer the timer goes undef in the
array of timers, when POE comes to that timer it will just hope over to the
next one. (this could ofcourse be designed without weakrefs but will consume
more memory).
package Timer;
sub new {
my $self = bless [time, state];
}
sub off {
$self->[state] = 0;
}
sub execute_timer{
if next_time->state == 0
execute_timer();
}
memory cost goes up because of empty array values, nothing else
artur
