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

[Christian Grothoff]

On 03/17/2017 01:10 PM, 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.

Hmm. As long as you suspend inside of the DH, we should just allow you
to not decrement upload_data_size.  I've checked Git master, and there
it is clearly OK (line 2020: if (... && (! suspended)) error();).  Did
not check if this was just recently fixed.

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

That you must not do, as it would mean running at 100% CPU in select().
> 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.

What you can do is simply "optimistically" resume a connection when
there is a _chance_ that you might be ready, an if it turns out you were
wrong, instantly suspend it again.

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

I think you can do so (now), and if it is really something that changed
between the time you resumed and the time MHD called you, it should be
acceptable (and in particular not result in busy waiting).

> 2) Is it possible to do so that the chain
> suspend-resume-suspend-resume will not affect read buffers?

We should definitively implement it like that.

I've put in the required logic to avoid MHD freaking out about the
"event loop without network activity" in
4a77c8eba2e3e4857dabb12fbb52920b0eb98a59

signature.asc
Description: OpenPGP digital signature