On 03/17/2017 01:10 PM, Vitaliy T wrote: > Hello, > > On 17 March 2017 at 10:03, Evgeny Grin <[email protected]> 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
