[Python-ideas] async: feedback on EventLoop API

Shane Green shane at umbrellacode.com
Tue Dec 18 13:37:58 CET 2012


Sorry for the utter lack of formatting etiquette in my previous responses everyone…  My message (the next sentence) was in response to the message below.  Sorry for the confusion..

	Sending the demultiplexed data through 15 pipes so the application actually is dealing with 15 streams of data using single callback notifications from the event loop seems like the more KIS approach, in this case…



> From: Nick Coghlan <ncoghlan at gmail.com>
> Subject: Re: [Python-ideas] async: feedback on EventLoop API
> Date: December 17, 2012 11:21:37 PM PST
> To: Guido van Rossum <guido at python.org>
> Cc: Antoine Pitrou <solipsis at pitrou.net>, python-ideas at python.org
> 
> 
> 
> 
> 
> 
>> Sorry, I wasn't quite clear on what I meant by gather/scatter and it's more a protocol thing than an event loop thing.
>> 
>> Specifically, gather/scatter interfaces are most useful for multiplexed transports. The ones I'm particularly familiar with are traditional telephony transports like E1 links, with 15 time-division-multiplexed channels on the wire (and a signalling timeslot), as well a few different HF comms protocols. When reading from one of those, you have a demultiplexing component which is reading the serial data coming in on the wire and making it look like 15 distinct data channels from the application's point of view. Similarly, the output multiplexer takes 15 streams of data from the application and interleaves them into the single stream on the wire.
>> 
>> The rise of packet switching means that sharing connections like that is increasingly less common, though, so gather/scatter devices are correspondingly less useful in a networking context. The only modern use cases I can think of that someone might want to handle with Python are things like sharing a single USB or classic serial connection amongst multiple data streams. However, I suspect the standard transport and protocol API definitions already proposed should also suffice for the gather/scatter use case, as such a component would largely work like any other protocol-as-transport adapter, with the difference being that there would be a many-to-one relationship between the number of interfaces on the application side and those on the communications side.
>> 
>> (Technically, gather/scatter components can also be used the other way around to distribute a single data stream across multi transports, but that use case is even less likely to come up when programming in Python. Multi-channel HF data comms is the only possibility that really comes to mind)
>> 
>> -- 
>> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>> 
>> 
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> http://mail.python.org/mailman/listinfo/python-ideas
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20121218/5086f164/attachment.html>


More information about the Python-ideas mailing list