Re: [libmicrohttpd] [PATCH]: MHD_connection_update_event_loop_info sends INTERNAL_ERROR for suspended connections

[Evgeny Grin]

On 17.03.2017 15:10, Vitaliy T wrote:
> Hello,
> 
> On 17 March 2017 at 10:03, Evgeny Grin <address@hidden> wrote:
>> Please note that even if you suspend connection, you must process at
>> least some data (preferably - all data) and decrement value of
>> 'upload_data_size'.
> 
> Yes, this was my mistake. Before suspending a connection I have to
> forgot about decrementing upload_data_size.
> 
> I have questions:
> 
> 1) Due the async nature of the MHD, how can I keep a connection in
> resume state _without_ reading data in DH?
> 
> I mean, I can't say in which moment I can resume the connection with
> guarantee to read the data. I have to create some kind of queue with
> tracking which connection is could read data and which ones could not.
> And more importantly that I must guarantee that if I resumed a
> connection and it must read full data.
> 
> Things getting complicated.
> 
> Current DH logic looks like that:
> 
> 1. I have to initialize internal structure per request, then it will
> be stored to con_cls and I return MHD_YES.
> 2. On the second entry into DH, I do process request: either upload a
> file, either suspend a connection.
> 3. When uploading the file has been finished I am resuming the next
> connection (if it is).
> 4. Even after resuming the connection there is a chance that a new
> connection will be proceeded before the "resumed" connection.
> 
> I can track if the connection was resumed and give it a higher
> priority. But if so I have to suspend _all_ new connections before
> doing something useful.
> I will think about it, but, IMHO, it is wrong that I can't
> suspend/resume connections when I want without reading buffers.
> 
> 2) Is it possible to do so that the chain
> suspend-resume-suspend-resume will not affect read buffers? Until I
> will "say" to MHD that I really read a data and we can continue in the
> normal mode. Because, by you words I can't resume a connection if I
> don't know will be it suspended again or not. I can resume the
> connection only if I give guarantees that it will be proceeded as
> usual (read all data).

Looks like you want to blindly resume connection and check whether to
process it only in callback handler.
I suggest to move check for "readiness to be processed" to some separate
function. Then instead of blindly resuming connection and immediately
suspending it again - resume connection only when you will be sure that
it's ready to be processed.
You don't need to make this check only inside callback function. If you
suspend connection and resume it later - connection conditions are not
changed, you will not get any new information in callback. So you can
store required information in your internal structures and check it
*before* resuming, not *after* resuming.

Resume/suspend repeated cycles without processing of information - is
ineffective and wastes a lot of resources.

-- 
Best Wishes,
Evgeny Grin

PS If you will check master on official git, you may find support of
your ineffective way of processing.