[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.
signature.asc
Description: OpenPGP digital signature
- [libmicrohttpd] Clarification on receiving on one thread, replying on another, Tom Cornell, 2016/10/24
- Re: [libmicrohttpd] Clarification on receiving on one thread, replying on another, Christian Grothoff, 2016/10/24
- Re: [libmicrohttpd] Clarification on receiving on one thread, replying on another, Tom Cornell, 2016/10/24
- Re: [libmicrohttpd] Clarification on receiving on one thread, replying on another, Christian Grothoff, 2016/10/24
- Re: [libmicrohttpd] Clarification on receiving on one thread, replying on another, Tom Cornell, 2016/10/25
- Re: [libmicrohttpd] Clarification on receiving on one thread, replying on another, Christian Grothoff, 2016/10/25
- Re: [libmicrohttpd] Clarification on receiving on one thread, replying on another, Tom Cornell, 2016/10/25
- Re: [libmicrohttpd] Clarification on receiving on one thread, replying on another, José Bollo, 2016/10/25
- Re: [libmicrohttpd] Clarification on receiving on one thread, replying on another, Christian Grothoff, 2016/10/25
- Re: [libmicrohttpd] Clarification on receiving on one thread, replying on another,
Christian Grothoff <=