[Top][All Lists]

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

Re: [libmicrohttpd] MHD_suspend_connection API

From: Jared Cantwell
Subject: Re: [libmicrohttpd] MHD_suspend_connection API
Date: Wed, 5 Feb 2014 10:05:49 -0700

So if you are not using a thread pool, does that mean you are using a thread per connection?  If so, what benefit does suspending a connection give you in that case, because you can just hold up the calling thread without a problem (it is dedicated to you anyway)?  We haven't tested without a thread pool.


On Tue, Feb 4, 2014 at 9:46 PM, Luke-Jr <address@hidden> wrote:
On Wednesday, February 05, 2014 3:08:14 AM Jared Cantwell wrote:
> 1. After we receive some data in the access handler callback
> (*upload_data_size > 0) we decide whether we've buffered enough internally,
> and if so, we call MHD_suspend_connection()
> We do not call this on the final callback with *upload_data_size == 0 since
> we will not get another callback from mHTTPD

Unfortunately, I want to read the entire upload buffer before I suspend.
Fortunately, this specific use case I'm trying to address would probably not
fail too badly if I defer all reading until after the suspend/resume.
Therefore, I have modified my code to suspend during the initial call to the
access handler callback (which also initialises *con_cls).

> 2. In the background (on another thread), we process the data we have
> buffered. If the buffer shrinks enough, we call MHD_resume_connection()
> 3. We will get called back in the access handler after we resume, and we
> have also seen occasional callbacks while suspended, which we ignore; we
> keep track of our suspended state.

Unfortunately, I am not seeing any callback after I call
MHD_resume_connection(). I do consistently get another callback immediately
after MHD_suspend_connection(), however...

What do you return from the callback after you do MHD_suspend_connection? If I
return MHD_NO, my connection gets closed, so I am returning MHD_YES for now.

> 4. We are running the server with these options:
> and we have passed in a value for MHD_OPTION_THREAD_POOL_SIZE to use a
> thread pool

My only difference here is not using a thread pool.


reply via email to

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