Hi Guido, On Thu, Oct 25, 2012 at 2:43 AM, Guido van Rossum <guido@python.org> wrote:
On Wed, Oct 24, 2012 at 4:26 PM, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
On 2012-10-24, at 7:12 PM, Guido van Rossum <guido@python.org> wrote:
Ok, I can understand. But still, this is a problem with timeouts in general, not just with timeouts in a yield-based environment. How does e.g. Twisted deal with this?
I don't know, I hope someone with an expertise in Twisted can tell us.
But I would imagine that they don't have this particular problem, as it should be related only to coroutines and schedulers that run them. I.e. it's a problem when you run some code and may interrupt it. And you can't interrupt a plain python code that uses callbacks without yields and greenlets.
Well, but in the Twisted world, if a cleanup callback requires more blocking calls, it has to spawn more deferred callbacks. So I think they *do* have the problem, unless they don't have a way at all to constrain the total running time of an action involving cascading callbacks. Also, they have inlineCallbacks which does use yield.
AFAIR, in twisted there is no timeout on coroutine, there is a timeout on request, which is usually just a socket timeout. So there is no problem of interrupting the code in arbitrary places. Another twisted thing, is doing all writes asynchronously with respect to user code, so if you want to write something and close a connection for finalization you just call: transport.write('something') transport.loseConnection() And they do not return deferreds, so it returns immediately even if the socket is not writable at the moment. (IIRC, it never writes right now, but rather from reactor callback) -- Paul