[Python-Dev] Socket timeout and completion based sockets
Kristján Valur Jónsson
kristjan at ccpgames.com
Wed Nov 28 13:13:15 CET 2012
I'm sorry, I thought it was something that people did more often, to create different implementations of of the "socket" api, for which cPython provided a mere reference implementation. I know of at least three different alternative implementations, so I thought that the question were clear enough: Is the timeout mechanism "supposed" to be re-startable for an api that aims to conform to the "socket" module, or is that a mere coincidence falling out from the select/bsd based reference implementation in cPython? The docs don't say either way.
(For c-level timeout mechanisms implemented for various c implementations of the bsd socket api, it is not uncommon to see it stated that after a socket operation times out, the socket is in an undefined state and should be discarded, e.g. here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms740476(v=vs.85).aspx " If a send or receive operation times out on a socket, the socket state is indeterminate, and should not be used; TCP sockets in this state have a potential for data loss, since the operation could be canceled at the same moment the operation was to be completed.")
Anyway, as for concrete requirements: The issue I have always seen with various asynchronous libraries is their lack of composability. Everyone writes their own application loop and event queue. Merely having a standard spec and reference implementation of an application main loop object, and main event queue object, in the spirit of WSGI, would possibly remedy this. You could then hopefully assemble various different libraries in the same application, including greenlet(*) based ones.
(*) Greenlets or stackless can be just another way of hiding asynchronous operations from the programmer. My favourite one, in fact. The main trick here is unwinding and replaying of calling contexts, the specific implementation by stack-slicking is mere technical detail, since it can be achieved in other ways (see soft-switching in stackless python)
> -----Original Message-----
> From: gvanrossum at gmail.com [mailto:gvanrossum at gmail.com] On Behalf
> Of Guido van Rossum
> Sent: 27. nóvember 2012 15:54
with stackless python.
> It would have been nice if you had given more context and stated your
> objective upfront instead of asking what appeared to be an obscure question
> about a technical detail
> Finally, I am not at all interested in greenlets
> very much unspecified at this point. NOW WOULD BE A GOOD TIME TO
> WRITE DOWN YOUR REQUIREMENTS.
> (*) Greenlets are a fine mechanism for some application areas, but ultimately
> not fit for the standard library, and they have some significant downsides.
More information about the Python-Dev