On 11:57 am, zoran.bosn...@sloveniacontrol.si wrote:
>Hello all,
>Thanks for all your comments.
>
>I have filed a ticket regarding this issue:
>http://twistedmatrix.com/trac/ticket/5552
>
>I hope it will be accepted as a problem.
Hi Zoran,
Thanks for the follow-up. We're already tracking this fe
Hello all,
Thanks for all your comments.
I have filed a ticket regarding this issue:
http://twistedmatrix.com/trac/ticket/5552
I hope it will be accepted as a problem.
regards,
Zoran
From: twisted-python-boun...@twistedmatrix.com
[twisted-python-boun...
On 02/22/2012 03:20 AM, Tristan Seligmann wrote:
> On Tue, Feb 21, 2012 at 1:05 PM, Phil Mayers wrote:
>> I realise this is tricky to solve, but I'll note it's not impossible for
>> really REALLY big clock skews to happen. For example: recently we had a
>> server kernel panic and need a cold reboo
On Tue, Feb 21, 2012 at 1:05 PM, Phil Mayers wrote:
> I realise this is tricky to solve, but I'll note it's not impossible for
> really REALLY big clock skews to happen. For example: recently we had a
> server kernel panic and need a cold reboot. The machine booted and read
> it's time from the CM
On 11:05 am, p.may...@imperial.ac.uk wrote:
>On 20/02/12 20:32, Glyph wrote:
>>Well, it depends on how you define a "bug". LoopingCall's internal
>>state remains consistent, but if you set your clock backwards,
>>LoopingCall won't fire your callback again until the system clock
>>catches up to whe
On 20/02/12 20:32, Glyph wrote:
> Well, it depends on how you define a "bug". LoopingCall's internal
> state remains consistent, but if you set your clock backwards,
> LoopingCall won't fire your callback again until the system clock
> catches up to where it previously was. Any new LoopingCalls
On Feb 20, 2012, at 12:52 PM, Phil Mayers wrote:
> On 20/02/12 14:29, exar...@twistedmatrix.com wrote:
>> On 12:09 pm, p.may...@imperial.ac.uk wrote:
>>> On 20/02/12 04:14, Itamar Turner-Trauring wrote:
See http://twistedmatrix.com/trac/ticket/2424
>>>
>>> I find that ticket disturbing read
On 20/02/12 14:29, exar...@twistedmatrix.com wrote:
> On 12:09 pm, p.may...@imperial.ac.uk wrote:
>> On 20/02/12 04:14, Itamar Turner-Trauring wrote:
>>> See http://twistedmatrix.com/trac/ticket/2424
>>
>> I find that ticket disturbing reading.
>>
>> The original description seems to claim there is
On 12:09 pm, p.may...@imperial.ac.uk wrote:
>On 20/02/12 04:14, Itamar Turner-Trauring wrote:
>>See http://twistedmatrix.com/trac/ticket/2424
>
>I find that ticket disturbing reading.
>
>The original description seems to claim there is a logic bug in
>LoopingCall that is triggered when the clock go
On 20/02/12 04:14, Itamar Turner-Trauring wrote:
> See http://twistedmatrix.com/trac/ticket/2424
I find that ticket disturbing reading.
The original description seems to claim there is a logic bug in
LoopingCall that is triggered when the clock goes back, but subsequent
discussion is all about
On Sun, 19 Feb 2012 16:49:23 +
Zoran Bošnjak wrote:
> Hello all,
> I was astonished to find out that looping call period depends on the system
> time by default. The periodic tick can even stall for a long time, if the
> system time jumps backwards during program execution. It turned out th
On Mon, Feb 20, 2012 at 12:14 PM, Itamar Turner-Trauring <
ita...@itamarst.org> wrote:
> On 02/19/2012 11:49 AM, Zoran Bošnjak wrote:
> > Hello all,
> > I was astonished to find out that looping call period depends on the
> system time by default. The periodic tick can even stall for a long time,
On 02/19/2012 11:49 AM, Zoran Bošnjak wrote:
> Hello all,
> I was astonished to find out that looping call period depends on the system
> time by default. The periodic tick can even stall for a long time, if the
> system time jumps backwards during program execution. It turned out that this
> is
13 matches
Mail list logo
