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. > 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. > 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. These are needed for stopping the loop from the outside, from another thread. They are not needed to stop the loop from the inside. It is possible that our threading capabilities for this will be more limited on Windows than on Unix until specific code is implemented (not by me) and unless the external library is used. Just as our threading capabilities are currently more limited on Windows. I insist: it is the opposite as what you are saying, this project makes it possible to have code that works on Windows, unlike now. It just will not be me who write specific code. Regards, -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ 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".
