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)

Cheers,

K

> -----Original Message-----
> From: gvanros...@gmail.com [mailto:gvanros...@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.
> 


_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to