Lynne (12021-02-19): > File descriptors are reference counted. So if something takes ownership > of an FD (completely reasonable, since it may want to clean up, seek, and > flush+close it afterwards), then you can just dup() it before giving > it to libuv.
You are completely misunderstanding the problem. A foreign protocol is a protocol for which we have a read function in a library; if the library is not bad, we can have it non-blocking; if the library is good, we can have the file descriptor behind for polling. When we have that, we can integrate it an event loop: add the file descriptor to our watch list; when poll() tells us it is readable, call the read function of the library. Many libraries can work like that, including libX11 and libxcb, ALSA, and actually, to some extent, libavformat. Many event loops can work like that, including libev, and Gtk+/GLib. It seems that libuv cannot work like that: it insists for doing the reading itself. > Windows is something we explicitly support. So we need something > which works on Windows as well, otherwise we still lose a very very > large majority of users. But we are primarily a Unix project, with a Unix culture and Unix-style code. If we forget this, we get something that half-way each and all the way bad. > That's some very prejudiced thinking. Their solutions are ugly because they > got paid for it? No, "throw money at the problem" means bigger hardware because the code is needlessly slow and not optimized, because they chose the easy solution. Regards, -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
