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

[Vitaliy T]

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

Thanks.

-- 
With Best Regards,
Vitaliy V. Tokarev