[FFmpeg-devel] [RFC] Event loop

[Lynne]

Feb 19, 2021, 14:52 by george at nsup.org:

> Lynne (12021-02-19):
>
>> https://github.com/libuv/libuv/tree/v1.x/docs/code
>> Pipes, file descriptors, sockets, examples.
>> The docs are even searchable: http://docs.libuv.org/en/v1.x/index.html
>>
>
> I have found all this. Nothing allows to handle a foreign protocol
> handled by existing code. It is even stated explicitly in the docs:
> everything assumes libuv owns the fd. That means no ALSA, no libX11/xcb,
> etc.
>

File descriptors are reference counted. So if something takes ownership
of an FD (completely reasonable, since it may want to clean up, seek, and
flush+close it afterwards), then you can just dup() it before giving it to libuv.


>> > Yes, that is a terrible trend. Throw memory and CPU at I/O performance
>> > instead of writing optimized code. POSIX threads never were a solution
>> > for parallel I/O.
>> They kind of are, since I/O is blocking on most platforms
>>
>
> No, they are not. We had non-blocking I/O working perfectly way before
> POSIX threads were even remotely stable.
>
> I have come to understands that "threads as a solution for I/O" is a
> Windows solution.
>

Windows is something we explicitly support. So we need something
which works on Windows as well, otherwise we still lose a very very
large majority of users.


>> You seem really prejudiced towards anything 'infected' by node, big data,
>> or http servers, but they've been solving the issues we have now since
>> before we knew we even had them.
>>
>
> Unfortunately, their solutions are industrial ones, i.e. throw money at
> the problem. I want a hacker solution: throw efficient programming at
> the problem.
>

That's some very prejudiced thinking. Their solutions are ugly because they
got paid for it? Maybe they got money because their hacker solutions failed
after someone put in much more effort than what's reasonable?
By that logic a lot of our code is also "throw money at the problem". Frame
threading for decoders is definitely up there. What about reference counted
frames?
There's a time and a place for hacker solutions, but this area's definitely not it,
unless TempleOS integration is more important than having Windows support.