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

Attachment: 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".

Reply via email to