Re: [libmicrohttpd] Semantics of MHD_run_from_select

[Evgeny Grin]

Hi Martin,

On 3 Sep 2017 16:08:22 +0200, Martin Steuer wrote:
> Hi,
> 
> What is the expected semantics of calling MHD_run_from_select with a MHD
> configured to use epoll in combination with an application side event loop?
> 
> I am diagnosing a problem with systemd-journal-remote which utilizes MHD
> to receive journal entries from remote hosts. Currently, when
> transferring a bigger journal, the remote side suddenly stops because it
> seems not to receive ACKs anymore. This is because MHD_run_from_select
> is left even if a connections' fd is still read-ready and
> systemd-journal-remote will call epoll_wait on the corresponding fd. If
> now the remote side does not send any more data epoll_wait will not be
> left because of the edge triggered nature of the descriptor.
> 
> With the internal event loop, MHD has access to the state of a
> connection and thus can decide if it'll have to call epoll_wait. For
> external event loops however that's not true. So my answer to the above
> question would be: MHD_run_from_select should never be left if there is
> any more data available to be processed by the application. For edge
> triggered epoll this is the only safe way of doing it I can think of.
> 
> As a proof of concept I tried a simple workaround (see attached patch)
> which seems to solve the problem (only works for reads), but I am sure
> that this solution is neither complete nor nice.
> 
> What's your opinion on this?

Looks like you do not use MHD_get_timeout() to get timeout value for
your external select().

If MHD has more data to send and any socket is still ready for sending
in "epoll mode", you will get zero timeout value. This is effectively
same result as you get in "select mode" - select() function will return
immediately when any socket is already ready.

-- 
Best Wishes,
Evgeny Grin

signature.asc
Description: OpenPGP digital signature