On Wed, 10 May 2017 21:57:17 +0300 Evgeny Grin <[email protected]> wrote:
> On 10.05.2017 10:31, José Bollo wrote: > > On Fri, 5 May 2017 21:09:21 +0300 > > Evgeny Grin <[email protected]> wrote: > >> Shouldn't be any change. > >> Could you provide minimal example? > > > > > > My feeling is that this is a typical use case and it should work > > with only one call to MHD_run. I also think that providing a way to > > resume a connection and sending the pending data without having to > > call MHD_run would help (but is not required). > > Hi Evgeny, > Thanks for clarifying and example. Thank you also for MHD! > MHD do not provide any obligation how many MHD_run() call should be > passed before something is processed. But calling it at least one time make sense. On the example, there is no threading but in real there is. At some point when the request it treated, the connection is resume (in some thread) and a call MHD_run is piped. It is a good design: I can make serial calls to MHD_run that can't be reentering and I can process the request/connection in some other thread. > You example works with older version only by coincidence. 8'{ gloups > If you > change polling function from epoll to poll() or select(), it will > require more MHD_run() calls. I made a test with a long reply and it required more call... > Moreover, latest versions sending responses with fewer MHD_run() > calls, especially in epoll mode. If you provide full response right > at time - it will be send immediately, no need to use MHD_run() more > times. That is not clear to me. Sometime, I don't need to suspend the connection and in that case, the response is sent immediately, yes. But when suspend/resume is requested, I never have never seen the response immediately sent. > However I'll make some changes to provide early resume in external > poll mode. You could try MHD from git master tomorrow. Quiet impatient... If I can help, tell me. Best regards José
