On 19/02/2021 19:34, Kieran Kunhya wrote:
On Fri, 19 Feb 2021 at 19:04, Nicolas George <geo...@nsup.org> wrote:
Kieran Kunhya (12021-02-19):
I don't have a strong opinion on either. But I think you can use
container_of on the fd.
Thanks. I find no trace of it in the docs:
http://docs.libuv.org/en/v1.x/search.html?q=container_of&check_keywords=yes&area=default
Can you be a little more precise?
The portability arguments have been compelling for libuv over libev, so
if we find a way of getting libuv to work for our needs, it would be
best.
Actually maybe you can't use container_of and mmap since the fd is not a
pointer...
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>.
A user context pointer is carried into callbacks via the "data" member of uv_handle_t
(and hence the same member in all subtypes of it, like uv_poll_t), see
<http://docs.libuv.org/en/v1.x/handle.html>.
I think we need to be clear here that libuv and libev are solving some of the
same problems but not really in the same way.
libev is essentially super-poll(): it gives you a uniform interface to whatever
the preferred synchronous multiplexing method is on your platform (epoll on
Linux, kqueue on BSD and derivatives, traditional BSD select on Windows, etc.).
For Windows, that of course only supports things to which the synchronous
multiplexing interface applies, which is network sockets only.
libev isn't really giving you anything which we don't have already, though the
common interface may be nice for other applications which also use libev.
libuv is trying to solve event loop problem in a uniform way across all
platforms, with no requirement that the underlying method is synchronous.
That lets it provide better support on systems which want to use asynchrous I/O
(like Windows with I/O completion ports), but has the consequence that it has
to own the sockets internally because the details of the multiplexer affect all
socket I/O. If the underlying method is asynchrous, then every socket call
will need additional detail that the user doesn't want to deal with (e.g.
send() becomes WSASend() with an OVERLAPPED argument on Windows so the result
can be delivered to an I/O completion port later).
In my opinion, we would be best off ensuring that we support the more general
solution in libuv (or, if libuv has separate problems which rule it out,
another library with the same approach such as libevent), since FFmpeg provides
cross-platform libraries which we would like to work properly on all systems we
support. This has future benefits for the systems which in current form would
be covered by libev, as asynchronous I/O becomes is becoming more common on
Unix platforms as well (e.g. io_uring on Linux) and we will be able to handle
it without another redesign.
Thanks,
- Mark
_______________________________________________
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".
