Re: [libmicrohttpd] issue with suspend/resume

[Evgeny Grin]

On 11.05.2017 10:13, José Bollo 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).
>>>   
> 
>> 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.

"At least one time" - correct approach.
May be more calls are required.
MHD require a lot of internal processing and to handle it correctly with
external polling you must also call MHD_get_timeout().
MHD also can run poll functions in internal threads, external poll could
provide better result if you intensively intermix polling and processing
MHD sockets and some other sockets.
If you are using MHD internal polling you could not care about MHD
timeouts, runs and processing. MHD will handle all those things
automatically.


> 
>> 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...

Correct, long reply always require many calls.

>> 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.

Starting from 0.9.53 implemented "fast track" for small (received by
single recv() and response is provided immediately) HTTP requests:
they are handled in one turn.
Suspend/resume always required additional processing.


>> 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.

Pushes to master several minutes ago.
Please ignore previous announcement - by some reason commit was not
pushed to master.

-- 
Wishes,
Evgeny

signature.asc
Description: OpenPGP digital signature