On 17/02/2021 20:57, Nicolas George wrote:
Mark Thompson (12021-02-17):
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?
I have no intention to write Windows code for this. Our current
protocols use poll() internally, this event loop will do the same, and
be exactly as portable as things are now.
But it will be modular: if somebody later wants to write specific code
for Windows, it will be possible and I will make sure it is as easy as
possible.
Does that sound acceptable?
I'm not sure you can avoid writing Windows code for this to work at all,
because I don't think poll() as we have now is sufficient to get the
functionality you want.
I also worry that codifying something in this form is going to exclude the
possibility of getting a better result on Windows later, because that wouldn't
involve file descriptors or internals calling default BSD send()/recv().
For example:
On 01/02/2021 19:14, Nicolas George wrote:
> The API would consist of just a few entry points:
>
> - allocate, init, free an AVScheduler;
> - allocate, add, alter, remove, free events;
> - start, run, stop the loop.
How are you going to implement altering/removing an event or stopping the loop?
On Unix you of course have an eventfd/self-pipe sitting in the poll() set on
the event loop to interrupt it. On Windows you can't, because those things are
not file descriptors.
- 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".
