Request interruption

[ChriD]

if i am running a client.get() in a boost thread like this

client::response httpResponse = httpClient.get(httpRequest);
while (!ready(httpResponse))
{
// doing stuff
boost::this_thread::interruption_point();
}

and i am calling "interrupt" on this thread. its getting not interrupted!
if i do a while loop and skip getting the request like this

while (true)
{
// doing stuff
boost::this_thread::interruption_point();
}

the interrupt works..

Bug? My Fault?

best regards
Chris

[ghost]

The HTTP Client implementation doesn't know about thread interruptions. Is
this a new feature of Boost.Thread?

On Fri Jan 30 2015 at 9:03:54 AM Christian notifications@github.com wrote:

if i am running a client.get() in a boost thread like this

client::response httpResponse = httpClient.get(httpRequest);
while (!ready(httpResponse))
{
// doing stuff

boost::this_thread::interruption_point();

}

and i am calling "interrupt" on this thread. its getting not interrupted!
if i do a while loop and skip getting the request like this

while (true)
{
// doing stuff

boost::this_thread::interruption_point();

}

the interrupt works..

Bug? My Fault?

best regards
Chris

—
Reply to this email directly or view it on GitHub
#492.

[ChriD]

boost threads can be interrupted by calling "interrupt" on the thread object. That does not kill the thread it only sets an internal var to true, so that boost threads know thay have to quit.

In the boost thread you have to call boost interruption points so the thread can handle this internal var and then the thread throws a "interrupt exception"

its described in the boost documentation -->

http://www.boost.org/doc/libs/1_54_0/doc/html/thread/thread_management.html#thread.thread_management.tutorial.interruption

[deanberris]

I think I know what's happening here -- is your httpClient declared in the same function that's being run in the thread? If it is, then that means exiting the function will cause it to destroy the httpClient object, and hence potentially cause the ongoing requests to hang.

If the httpClient is shared among many threads, then that should allow the threads polling for ready(...) to exit cleanly without having to wait for ongoing requests to finish. Of course that doesn't mean that the requests will be cancelled, which is something the implementation doesn't support.

Can you confirm that the httpClient object isn't declared in the same function? If it is, consider moving it out and sharing it across multiple threads (it should be thread-safe after all).

[ChriD]

indeed, this was the problem!
declaring the client outside of the thread solved it! the interrupt is beeing procceserd and the thread is closing, Of course the Request is not aborted and that leads me to the next Problem. :(

If i now delete the class object where the thread is defined. it get stuck. i think its waiting for the request to finish in the destructor, but the request will maybee never finish. This are long polling requests which means they only return if there is some data to return.

is there any way to destroy the client without have it waiting for the request?

[ghost]

This is actually a limitation in the implementation of the client. :(

I suspect it’s possible to make this happen, but I don’t have time to do it.

Would you be interested in trying to implement this?

On Feb 3, 2015, at 5:21 AM, Christian notifications@github.com wrote:

indeed, this was the problem!
declaring the client outside of the thread solved it! the interrupt is beeing procceserd and the thread is closing, Of course the Request is not aborted and that leads me to the next Problem. :(

If i now delete the class object where the thread is defined. it get stuck. i think its waiting for the request to finish in the destructor, but the request will maybee never finish. This are long polling requests which means they only return if there is some data to return.

is there any way to destroy the client without have it waiting for the request?

—
Reply to this email directly or view it on GitHub #492 (comment).

[ChriD]

at least i can try it ;-)