libmicrohttpd
[Top][All Lists]
Advanced

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

Re: [libmicrohttpd] Developing async responses


From: Christian Grothoff
Subject: Re: [libmicrohttpd] Developing async responses
Date: Fri, 30 May 2014 16:16:07 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10

Hi!

There is no problem with your approach 2, that's how you should do it.
The reason why you cannot change the status code after queueing the
response is that MHD will put that part of the response on the wire
at that time --- only the body is transmitted later.  So use
suspend/resume and you should be fine.

Happy hacking!

Christian

On 05/30/14 08:44, Marcos Pindado Sebastian wrote:
> Hi, thanks for this fantastic library.
> We have used in the past microhttpd with internal select and thread per 
> connection successfully.
> This time however, we are interested in developing a way to produce 
> asynchronous responses, because we need to use another asynchronous
> Framework. Besides, we do not want the thread per connection this time to 
> avoid spawning many threads.
> 
> We have implemented several tests based in the archive posts for async 
> responses using the EXTERNAL SELECT mode, in two ways:
> 
> - The first way is to queue a ContentReaderCallback in the accessHandler 
> function, which returns 0 while response has not arrived.
> - The second way, is not queuing any response in the accessHandler function 
> and return MHD_YES, queuing the response when it arrives.
> We use an eventFd in the external loop to notify the main select of the 
> arrival of the asynchronous responses.
> 
> The first solution Works great but has a problem. Apparently, there is no way 
> to change the HTTP responseCode after the response is queued. So, if i was to 
> return an specific http error code from the async framework I could not do it 
> (without hacking the library or including the internal types).
> 
> The second solution has the main disadvantage that does busy waiting. The 
> workaround for this is suspending the connection on the accessHandler and 
> resume it when the response arrives just before queuing the response.
> 
> Do you find any problem in using approach 2? (Appart from not being notified 
> when a client disconnects)
> Is there a way of changing statusResponse in approach 1?
> 
> Thanks in advance
> 
> Marcos
> 
> ____________
> Verificada la ausencia de virus por G Data MailSecurity
>  
> VersiĆ³n: AVA 24.2366 del 30.05.2014 
> Noticias de virus: www.antiviruslab.com
> 



reply via email to

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