On Mon, Oct 29, 2012 at 9:03 AM, Richard Oudkerk shibturn@gmail.com wrote:
On 29/10/2012 2:47pm, Guido van Rossum wrote:
Kind of. I think if it was an important use case it might affect the shape of the API. However I can't think of a use case where it might make sense for two tasks to read or write the same file descriptor without some higher-level mediation. (Even at a higher level I find it hard to imagine, except for writing to a common log file -- but even there you want to be sure that individual lines aren't spliced into each other, and the semantics of send() don't prevent that.)
It is a common pattern to have multiple threads/processes trying to accept connections on an single listening socket, so it would be unfortunate to disallow that.
Ah, but that will work -- each thread has its own pollster, event loop and scheduler and collection of tasks. And listening on a socket is a pretty special case anyway -- I imagine we'd build a special API just for that purpose.
Writing (short messages) to a pipe also has atomic guarantees that can make having multiple writers perfectly reasonable.
That's a good one. I'll keep that on the list of requirements.