libmicrohttpd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libmicrohttpd] Clarification on receiving on one thread, replying o


From: Christian Grothoff
Subject: Re: [libmicrohttpd] Clarification on receiving on one thread, replying on another
Date: Tue, 25 Oct 2016 19:44:50 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

On 10/25/2016 05:45 PM, Tom Cornell wrote:
> 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!

Great.

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

More or less -- the key difference being that what you find in
"*con_cls" is totally up to the application.  Usually a more complex
application would store some struct in "*con_cls" with a state machine
that performs a setup in step 0 to 1, tracks an upload through stages
2-3, triggers some application logic in step 4 and provides the final
response in stage 5.  Oh, and stage 0 would be the URI log callback,
which is of course optional.  Finally, you might have stage 6 (the
completion callback) to clean up.

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

You're welcome.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]