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.«
