On Sun, Oct 28, 2012 at 11:22 PM, Christopher Armstrong <
ra...@twistedmatrix.com> wrote:
> On Sun, Oct 28, 2012 at 1:28 PM, wrote:
>
>> On 05:57 am, dynami...@gmail.com wrote:
>> >Hi All
>> >
>> >I am quite concerned the ticket 2424 due to our system use
>> >reactor.callLater almost anywhere
On 10/28/2012 10:16 PM, Tristan Seligmann wrote:
> On Mon, Oct 29, 2012 at 12:05 AM, Phil Mayers wrote:
>> This depends on how you're running ntpd. If you have "-x" on the command
>> line, yes - ntpd will not step.
>>
>> If not, there are circumstances it will step - clock diffs in excess of
>> 12
On Mon, Oct 29, 2012 at 10:33 AM, Phil Mayers wrote:
> On 10/28/2012 10:16 PM, Tristan Seligmann wrote:
>> On Mon, Oct 29, 2012 at 12:05 AM, Phil Mayers
>> wrote:
> Sadly, this is not the case. As has already been pointed out, virtual
> machine clocks can undergo stepping in "normal" oepration.
On 28 Oct, 08:40 pm, _...@lvh.cc wrote:
>
>For some reason I thought IProtocol.makeConnection did that; I guess
>it's
>because the implementation in Protocol sets the `transport` attribute
>(I
>thought it was the other way around).
>
>I've set transport.protocol = myNewProtocol and now there's on
On Mon, Oct 29, 2012 at 5:59 PM, Tristan Seligmann
wrote:
> On Mon, Oct 29, 2012 at 10:33 AM, Phil Mayers
> wrote:
> > On 10/28/2012 10:16 PM, Tristan Seligmann wrote:
> >> On Mon, Oct 29, 2012 at 12:05 AM, Phil Mayers
> wrote:
> > Sadly, this is not the case. As has already been pointed out, vi
On Oct 29, 2012, at 2:59 AM, Tristan Seligmann wrote:
> I don't think anyone in this thread is arguing *against* implementing
> this functionality; I think the point was just that this functionality
> is only of critical importance under a limited range of circumstances,
> as opposed to being so
On Oct 29, 2012, at 8:02 AM, exar...@twistedmatrix.com wrote:
> On 28 Oct, 08:40 pm, _...@lvh.cc wrote:
>>
>> For some reason I thought IProtocol.makeConnection did that; I guess
>> it's
>> because the implementation in Protocol sets the `transport` attribute
>> (I
>> thought it was the other
On 29/10/12 09:59, Tristan Seligmann wrote:
> I don't think anyone in this thread is arguing *against* implementing
> this functionality; I think the point was just that this functionality
> is only of critical importance under a limited range of circumstances,
> as opposed to being something of u
Hi,
I've got a question regarding
deferToThread / runWithConnection
I have a network server that accepts RPCs and forwards those to a relational
database calling stored procedures.
The call of the stored procedures is happening via "runWithConnection" .. that
is on a background thread pool (s
On Oct 29, 2012, at 10:52 AM, Phil Mayers wrote:
> On 29/10/12 09:59, Tristan Seligmann wrote:
>
>> I don't think anyone in this thread is arguing *against* implementing
>> this functionality; I think the point was just that this functionality
>> is only of critical importance under a limited r
10 matches
Mail list logo