[FFmpeg-devel] [RFC] Event loop

[Nicolas George]

Mark Thompson (12021-02-20):
> I'm not entirely sure where this discussion was going, but I believe
> the original questions would have been simple to answer if anyone had
> bothered to read the documentation.
> 
> Adding a file descriptor referring to something independent of libuv
> (such as an alsa or xcb fd) is handled by uv_poll_init(), see
> <http://docs.libuv.org/en/v1.x/poll.html>.

I had looked in the documentation, but not read it entirely, and I had
missed this part. I was precisely to get help finding the relevant
tidbits that I asked here.

I want to take the occasion to explain how this discussion is going, in
my opinion.

Lynne, this is in great part for you.

When I exposed my prejudices against Node, it was not to close the
discussion, it was not a rejection. Quite the contrary, I was opening
the discussion, I was inviting precisions: I pointed that my prejudices
were weak, and that I knew they were, and I expected somebody to correct
me with more accurate information relevant to the discussion.

Somebody could have pointed to me that the horrible strace output of
Node is not the fault of libuv, that libuv does all the necessary things
to use efficiently the available system features.

(About my opinions on industrial development, I believe they are
founded, but they are not relevant, as they relate to practices that are
commonplace there, but are absolutely not what libuv does.)

Now that I have looked into it more carefully, I can say that libuv
seems pretty good. Apparently, it does the right thing wherever I
looked.

In fact, what libuv does looks a lot like what I want to do with
libavformat.

If we were looking for a library to found our network protocols upon,
then libuv would be probably an excellent candidate.

But that is not what we are doing.

The policy of this project has always been: no hard dependencies for
core features.

Network protocols are a core feature, at least some of them. We cannot
depend on libuv for them.

There is another policy: we do not chose a side. We do not decide if
OpenSSL is better than GnuTLS, we support both.

For these reasons, we are not looking for a single library to base the
protocols. We will do that ourselves, and we are looking for libraries
to bring extra features and most importantly to prove that the new
design is usable with them.

The last point is very important. Even if we finally decide to go with
libuv, we must make sure that other applications will be able to use
libev, and GLib/Gtk+, and Qt.

And that means we cannot use the advanced features of the libraries, we
need to stay with the basic features that are available, one way or
another, in all of them.

I know that GLib/Gtk+, libev and Qt are compatible with each other and
with the design that is immediately obvious for an experienced Unix
developer. This is what I intended to do.

For a time, it seemed that libuv was not compatible, not compatible with
GLib/Gtk+, libev and Qt and not compatible with the obvious design. That
would have meant it was too high-level for our needs. That would have
removed a promising option from our choices, but that would not have
been terrible.

Fortunately, Mark found the bit that was missing, so we can go ahead.

But there was another option, and there still is.

We can decide to change the policy. We can decide that the way libuv
does things is good, and we want to use it, and FFmpeg will depend on it
to become better.

This is not what we were discussing, but we can discuss it.

I have no intention of undertaking this discussion, but I think it could
be a good idea, and I would not oppose it, quite the contrary.

So, Lynne, if you want to defend this change in policy, please go ahead,
you have my support.

But otherwise, it seems we can use libuv, but we will still have to
restrict to its basic features.

I hope this makes things clearer and removes any aggression that may
have seeped into the discussion.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20210223/ecbacbfa/attachment.sig>