Lynne (12021-02-19): > You poll it in a busy loop in a thread in an event.
Yeah. Events loop are supposed to avoid busy loops. So no. > Or you find a solution to use libuv's polling instead via a "hacker > solution". This is what I am asking: can you give a good solution with libuv? It seems you cannot. > Or you simply don't use its mmap API, because polling-only sound systems > only made sense in the 90's. Yeah, let us not use the more efficient API because the library does not support it is not a great argument. And it was only an example. Sometimes, it's an ioctl that needs to be done. Sometimes it's just that the library handling the protocol expects the data on the file descriptor and not already read by another library. All this discussion has proven that libuv is not suited for our use. it may be great for the kind of things it is meant for, but it is just not what we, FFmpeg, need. > This is as far as I'm willing to take this discussion. You're stubbornly > unwilling to > see any reason and you openly cite your biases as a reason to hate libuv, > Windows or threads. > Next time if you have absolutely no interest in any other solution apart from > it > being a opportunity to express your opinions, don't ask. This is untrue. I have expressed my biases as replies to your own biases ("only made sense in the 90's" and such), but the arguments I base my decision on are technical. And in this case it is not just a matter of preference. I was convinced to use libuv, I looked how to do it, and only then found it seemed it was not possible. > You can proceed on your own, but you don't have my support. If the patch ends > up > locking us up with libev or its unmaintained Windows forks I'll voice my > disapproval > and we'll end up with exactly the type of situation this RFC was meant to > resolve. It seems you have missed the part where I mentioned the design will be modular. That's not too bad, I only repeated it half a dozen times. And that is the core of the problem. We may be able to use libuv if we sacrifice devices, but we would be able to use ONLY libuv. Nor our own lightweight implementation, nor a completely different event loop provided by the application. This is not what we want. 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".