On Mon, Jul 20, 2009 at 7:33 AM, Ilya Etingof wrote:
> Isn't this call priority policy appears somewhat rigid and obscure?
>
> Would it be clearer if user would be allowed to assign relative
> weights to his/her receiption and timer functions so that main loop
> could choose what to call in case
>> Perhaps it works that way. And what makes things worse is that if datagram
>> input rate is steady and higher than datagram processing time, the
>> LoopingCall calls will never be invoked.
>
> It will eventually stop reading datagrams and go do something else. The
> exact way it decides when t
On Mon, Jul 20, 2009 at 6:52 AM, Phil Mayers wrote:
> Fascinating though the topic is, I very much doubt I'll have any time to
> even look at it.
>
A familiar refrain.
That said; is there a reactor "performance" test?
Hmm. No, not really. It would be helpful to develop one, I think.
Especial
>
> I know what you mean. If you trawl through my really old blog posts
> (I think the one I'm thinking of is on livejournal, but I can't find
> it quickly) you'll see that I've thought about this before. The two
> main deterrents to changing the reactor to be a set of abstract
> "events" placed
On Sun, Jul 19, 2009 at 10:43 AM, Phil Mayers wrote:
> Viewing the reactor as a device that emits a stream of events (timer
> ticks, socket reads, write requests etc.) the problem can be considered
> a QoS issue. It's hard to see how the reactor could "know" how to do
> the right thing in all cas
On Sun, Jul 19, 2009 at 02:58:40PM +0100, Jean-Paul Calderone wrote:
>
>It will eventually stop reading datagrams and go do something else. The
>exact way it decides when to stop is completely arbitrary and I don't
>think anyone has ever demonstrated that it's clever or appropriate in the
>general
On Sun, 19 Jul 2009 17:20:46 +0400 (MSD), Ilya Etingof wrote:
>
>>> But why main loop does not fire timed events when it has a chance to do
>>> that? Note that my data processor takes 0.2 sec on each run, while my
>>> timed event period is 1 sec.
>>>
>>> In other words, I'd understand this behavio
>> But why main loop does not fire timed events when it has a chance to do
>> that? Note that my data processor takes 0.2 sec on each run, while my
>> timed event period is 1 sec.
>>
>> In other words, I'd understand this behavior if my data processor
>> would block main loop for a few periods of
On Sun, Jul 19, 2009 at 09:01:34AM +0100, Ilya Etingof wrote:
>
>[ skipped ]
>
>> The above is something which you're more or less not allowed to do in a
>> Twisted application. That simulated data processing is blocking the
>> main event loop. Nothing else happens until it finishes - that includ
[ skipped ]
> The above is something which you're more or less not allowed to do in a
> Twisted application. That simulated data processing is blocking the
> main event loop. Nothing else happens until it finishes - that includes
> handling more UDP packets and it includes running timed events
On Sun, 19 Jul 2009 01:04:25 +0400 (MSD), Ilya Etingof wrote:
>
>After doing some more research, I've realised that my previous
>conclusion and complaint was indeed inaccurate. Sorry for that!
>
>Now it looks to me that if my datagram receiver function takes some
>time for data processing, rapidly
After doing some more research, I've realised that my previous
conclusion and complaint was indeed inaccurate. Sorry for that!
Now it looks to me that if my datagram receiver function takes some
time for data processing, rapidly coming datagrams tend to stack up and
my timer function is not gett
> "Glyph" == Glyph Lefkowitz writes:
Glyph> On Sat, Jul 18, 2009 at 3:33 PM, Ilya Etingof wrote:
>> I can't get Twisted reactor calling my function in a more or less
>> periodic fashion with the LoopingCall mechanics.
>>
>> With select()-based reactor, the LoopingCall object seems to call bac
On Sat, 18 Jul 2009 23:33:51 +0400 (MSD), Ilya Etingof wrote:
>
>Dear Twisters,
>
>I can't get Twisted reactor calling my function in a more or less
>periodic fashion with the LoopingCall mechanics.
>
>With select()-based reactor, the LoopingCall object seems to call back my
>timer function only o
On Sat, Jul 18, 2009 at 3:33 PM, Ilya Etingof wrote:
> I can't get Twisted reactor calling my function in a more or less
> periodic fashion with the LoopingCall mechanics.
>
> With select()-based reactor, the LoopingCall object seems to call back my
> timer function only on select() timeout. If I/
Dear Twisters,
I can't get Twisted reactor calling my function in a more or less
periodic fashion with the LoopingCall mechanics.
With select()-based reactor, the LoopingCall object seems to call back my
timer function only on select() timeout. If I/O pace does not allow
select() to time out,
16 matches
Mail list logo
