This topic is very interesting. Is it the same issue when an external select/poll is used?
Best regards José Bollo Le mardi 25 octobre 2016 à 11:45 -0400, Tom Cornell a écrit : > On Tue, Oct 25, 2016 at 04:11:12PM +0200, Christian Grothoff wrote: > > > > On 10/25/2016 03:59 PM, Tom Cornell wrote: > > > > > > I will rework the code along the lines you suggest. Thanks for > > > the > > > quick reply! > > > > Ok, if it still doesn't work, I suggest you come back with a > > minimal > > example for us to look at -- easier to discuss with concrete code. > > It is working fine now. Thanks again! > > Basically, to sum up what I now think I understand, > you can be in any of 4 or 5 states when the access handler > callback is called: > > 1. New connection (*con_cls is null) > 2. Receiving data (*con_cls is not null, *upload_data_size > 0) > 3. Received all data (*con_cls is not null, *upload_data_size is 0) > Aaaaand the ones I was missing: > 4. Waiting for response (*con_cls is not null, *upload_data_size is > still 0, > and the part of *con_cls that holds your response is not filled > in) > 5. Response ready (*con_cls now holds a response) > > If you suspend your connection before returning in state 3, > and resume it only once the response is in place, > then you will never see state 4. > > And of course you only see states 4 and 5 if you return from state 3 > without having queued a response already. > > Is that more or less correct? > > By the way, I've been using MHD for several years now and have been > really happy with it. In this world of interacting networked > services, > MHD has become one of the tools I use most. So thank you for all > the work you have put into it! It shows. > >
