Re: [Twisted-Python] Raising exception from a Deferred canceller.

Thank you, Kai, for a great post describing the issue in detail. On Aug 29, 2013, at 2:27 AM, zhang kai wrote: > So, what’s your opinion on raising an exception from the canceller? I feel pretty strongly that it ought to be handled in this manner: Index: twisted/internet/defer.py =

Re: [Twisted-Python] Raising exception from a Deferred canceller.

JP writes: On Thu, Aug 29, 2013 at 1:00 PM, wrote: > Keep in mind that the Deferred cancellation API is a "best effort" API. > There are no guarantees that anything can be cancelled. Consider the fact > that 90% or more of Deferreds out there don't even have cancellation > implemented for them

Re: [Twisted-Python] Raising exception from a Deferred canceller.

JP writes: On Thu, Aug 29, 2013 at 1:00 PM, wrote: > What about a third option - if a cancellation function raises an > exception, fail the Deferred with that exception. I really like this idea, but it wont work if the cancel function has already fired the deferred. Terry

Re: [Twisted-Python] Twisted serialport dataReceived() provides fragmented data

On 29/08/13 17:15, Sivakumar Balasubramanian wrote: Dear Phil, I replaced thye dataReceived function by stringReceived, and ran the code. But when I do this, the program does not even enter the stringReceived function. That implies your protocol isn't an int16string-prefixed one. I assumed it

Re: [Twisted-Python] Twisted serialport dataReceived() provides fragmented data

Phil Mayers imperial.ac.uk> writes: > > On 29/08/13 16:38, Sivakumar Balasubramanian wrote: > > > Is there something that I doing wrong in my code? > > Yes. You are sub-classing Int16StringReceiver, but then breaking things > by overriding dataReceived. You should be implementing stringReceiv

Re: [Twisted-Python] Twisted serialport dataReceived() provides fragmented data

On 29/08/13 16:38, Sivakumar Balasubramanian wrote: Is there something that I doing wrong in my code? Yes. You are sub-classing Int16StringReceiver, but then breaking things by overriding dataReceived. You should be implementing stringReceived, and you'll get complete strings. dataReceived

[Twisted-Python] Twisted serialport dataReceived() provides fragmented data

I am tyring to implement a python program, using Twisted, to communicate witha bluetooth device. The following is a sample code of what I have implemented: from twisted.internet import protocol, reactor from twisted.internet.serialport import SerialPort from twisted.protocols import basic class D

Re: [Twisted-Python] Raising exception from a Deferred canceller.

On 10:18 am, te...@jon.es wrote: Hi Kai [snip] 2b) there is some kind of exception when cancel calls the cancellation function. I don't think 2a) is really an exception situation, so it makes sense, as you say, just to return False from cancel in this case. It's basically the cancel function

Re: [Twisted-Python] Raising exception from a Deferred canceller.

On 09:27 am, kylerzhan...@gmail.com wrote: Hi, As itamar mentioned in ticket #6676 , If a cancellation function for a Deferred throws an exception(the cancel() method of Deferred won’t throw exceptions, but the canceller may), behavior is undefined. If the cancellation func

Re: [Twisted-Python] Raising exception from a Deferred canceller.

Hi Kai I think it's helpful to keep clear on two different things that cancelation is intended to do: 1) to fire the original deferred so that things relying on it can proceed, and 2) to try to terminate an ongoing action that the deferred might be waiting on. For 1, I think calling cancel() shou

[Twisted-Python] Raising exception from a Deferred canceller.

Hi, As itamar mentioned in ticket #6676 , If a cancellation function for a Deferred throws an exception(the cancel() method of Deferred won’t throw exceptions, but the canceller may), behavior is undefined. If the cancellation function throws an exception it is currently not ca

Re: [Twisted-Python] Graceful shutdown

Thanks for the link. Looking at your code I found the magic lines I was missing. Implementing my own HTTPChannel was the key to success. Now I don't have to poll reactor.getWriters() to see if there are unfinished writers. I ended up with something like this: class ApiHTTPChannel(HTTPChannel):