On 01/02/2021 19:14, Nicolas George wrote:
Based on this discussion, I say that the need for an event loop is
confirmed.
I will now start discussing actual plans for going forward. Since the
coding work will be significant and not incremental, I want the outcome
of this discussion to be binding: if we agree to do it a certain way,
then the code for doing it will be accepted, pending code quality or new
unforeseen issues. If anybody objects to this, please explain your
reasons.
First, again: Why we need an event loop.
We need an event loop because we already have several ones. We already
have five protocols and two devices implementing their own event loops.
Factoring this duplicated code and implementing it properly is just the
obvious way forward.
Plus, it makes implementing new protocols simpler, especially when they
are somewhat complex. And it can make applications simpler.
So, my plan. Note that a lot of it will need to be ready before anything
can be applied.
...
I can see that this is all sensible stuff on Unix, but can you explain a bit
more of what your Windows implementation is going to look like?
The current file descriptor model with select() only admits the things which
are associated with file descriptors on Windows, which means BSD sockets only
(no eventfds or self-pipes to signal things to your event loop).
If you want the send()/recv() calls to feed back into an I/O completion port
for a Windows-style event loop then a lot more needs to change, because
everything will have to be able to instead call WSASend()/WSARecv() with
additional options.
- Mark
_______________________________________________
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".
