Feb 19, 2021, 15:52 by geo...@nsup.org: > 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. >
That's okay, I'd let it read and call events as they happen on the fds. I've written several pollin/pollout loops for Wayland FDs before and if possible I'd rather not have written them at all. >> 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. > I'm not even going to respond to this... >> 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. > Not going to respond to this either. But I'll say this: maybe it's better that you don't actually get in touch with anyone from libuv or otherwise, or if you do please don't mention anything about FFmpeg. _______________________________________________ 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".
