[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[libmicrohttpd] Semantics of MHD_run_from_select

From: Martin Steuer
Subject: [libmicrohttpd] Semantics of MHD_run_from_select
Date: Sun, 3 Sep 2017 16:08:22 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1


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?


Attachment: libmicrohttpd-continued-read.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]