On 18/02/2021 15:39, Nicolas George wrote:
Mark Thompson (12021-02-17):
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'm sure I can avoid writing Windows code, because, as I have already
pointed, our current implementation already work using poll(). If it
currently works, I have no intention of breaking it, just reorganizing
it to make it work better and make easier to extend.
If the existing remote-socket-only poll is sufficent (so no local events), then
I think I have misunderstood your original definition of the event loop because
I was expecting that other threads would be able to interact with it.
Would it be possible to add an example what you intend API use to actually look
like to your design summary? (In loose pseudocode.)
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().
You have got it backwards: it will make the possibility of getting a
better result on Windows later easier, because it will make everything
modular.
In fact, libev and libuv already implement code specific to Windows, so
we get them for free as soon as we implement support for one of these
libraries.
libev does not implement enough Windows support to be used generally, though it
is sufficient if you know the event loop will never want to interact with
anything which is not a socket (it hacks up self-pipes by connecting TCP
sockets to random ports on localhost).
I believe that libuv and libevent both implement it properly (I have no
experience with libuv, but Lynne seems to be advocating for it), so I would
strongly recommend starting your implementation using one of them in order to
ensure that you don't end up tied to the Unix model in an unhelpful way. (Note
in particular that this means essentially everything dealing with sockets has
to be delegated to the event library so that it can deal with asynchronous
calls internally, especially send()/recv() calls.)
Thanks,
- 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".
