Oh, it's just about multiple readers (or writers) per FD? We did consider that during the design phase and we couldn't come up with any use cases that weren't better off remaining unsupported. If you were thinking of speeding something up this way, think again -- the whole point of an event loop is that event handling is serialized. (In a different world, without the GIL, a different, multi-threading API might be possible, but you'd be paying for synchronization in some other way.)
On Sat, Feb 22, 2014 at 12:25 PM, Nikolaus Rath <[email protected]> wrote: > Hi Guido, > > In my specific case, the fd is an implementation detail, so this is not > an issue. But I was wondering if there may not be cases where this > becomes a problem. > > Having multiple callbacks waiting to read data from a fd is probably > pretty fragile, because you wouldn't know which reader got which part of > the input.. but maybe there are cases where the input comes in > independent, fixed size chunks that can always be read in a single recv > call? Or maybe someone wants to know when the fd is ready for IO without > actually intending to perform io (for something like a monitor). It just > strikes me as an odd decision to implicitly require that there can be > only one reader per fd... > > Best, > Nikolaus > > > Guido van Rossum <[email protected]> writes: > > What kind of contract does your library have with its users about that > fd? > > > > On Friday, February 21, 2014, Nikolaus Rath < > [email protected]> wrote: > > > >> Hello, > >> > >> I am confused by the fact that the BaseEventLoop.remove_{reader,writer} > >> methods only take an *fd* argument. If I'm writing a library, and the fd > >> originates outside of my control, how can I prevent to accidentally > >> remove the wrong callback, and prevent my callback from being removed by > >> other code? > >> > >> Best, > >> Nikolaus > >> > >> -- > >> Encrypted emails preferred. > >> PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C > >> > >> »Time flies like an arrow, fruit flies like a Banana.« > >> > > > > > > -- > > --Guido van Rossum (on iPad) > > > -- > Encrypted emails preferred. > PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C > > »Time flies like an arrow, fruit flies like a Banana.« > -- --Guido van Rossum (python.org/~guido)
