Quoting Nicolas George (2021-01-02 12:28:30) > Anton Khirnov (12021-01-01): > > I do not think this is a good idea. There are enough event loops in the > > world and making yet another one is not in scope for us. What we should > > do instead is allow clean integration with existing event loops, mainly > > by exporting the underlying file descriptors so they can be poll()ed on. > > We must do that indeed, but that is not enough, you are missing part of > the problem: FFmpeg has complex protocols that rely on several sockets, > and that is 100% part of the scope. Currently, these protocols are > implemented with an unsavory mix of polling and short timeouts. To fix > them and make them properly usable, we need an event loop.
I don't see how that conclusion follows. If a protocol has multiple FDs, we design the API to allow exporting multiple FDs. Why would we absolutely need our own event loop? > > So, we have only two choices (I consider "leaving everything in the mess > it is" is not a choice): implement our own event loop or choose one as a > mandatory requirement. AFAIK, adding new mandatory requirements is not > the preferred policy. It seems massively preferable to leave the choice of an event loop (if any - polling is still a viable alternative for many simple cases) to the user. -- Anton Khirnov _______________________________________________ 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".
