Hi Ovanes,

not documented. I tested this with gcc compiler and it worked. May be this would be a possible fix for asio developers to promise that synchronous sockets are interruptable via boost::thread interruption.

Actually in my case it was a prototype, and it stayed so and I probably would never rely on that in the production code, but wanted to show that there might be a quick fix for this issue.

Well, an interesting approach. Alas, I'd rather not stray so far into the realm of workarounds but try to solve the issue in a more standard and mean-to-be way. Also it has to work on windows and several unix flavours. My favorite solution would be the boost community would consider to include timouts in sync IO hence making it useful and adding value to asio. I'm not sure whether I understand correctly what you suggest but wouldn't that affect the socket itself rather than the code using it? In my case the socket is a static object and protected via mutex so there's no thread ownership in general sense. Cazart, Stephan

Hi Ovanes,

Well, my suggestion was the following: If the socket is blocked in a thread, the thread is blocked as well (and luckily boost::thread recognizes it as an iterruption point). Issue interrupt to that thread and the socket's wait will be interrupted. I don't remember If the socket is consistent after this operation, but I know it worked and I was able to close it as if nothing happened.

Hope that clarifies the issue,

Ah, right. Yes it does. That seems rather tricky to implement. I just had a little try on it and I noticed that in order to interrupt the thread calling the blocking wait one would need this thread's boost::thread object. Which cannot be obtained from the this_thread::id. So each thread calling that interruptable receive would have to have it's boost::thread object to pass it to the function, right? I can't see how I could expose all this to the interface of this method. I think it has to be closer to asio. Cheers, Stephan

Hi Ovanes,

...

So each thread calling that interruptable receive would have to have it's boost::thread object to pass it to the function, right? ... Yes, you probably need to pass a thread reference to be interrupted after some timeout, otherwise that would not work.

Well, I just tried to work around that with io_services running thread pools and all but there's little hope as all things I could come up with that realize this would require the thread object. The only thing I could imagine would be an extra thread which could be created to execute the blocking IO starts, while the original thread goes into a sleep that can be interrupted by the new thread upon successfuly return of the blocking read. like this (pseudo): void readthread() { // go into blocking read sock.sync_receive_from(...); } original thread: ... thread t1(readthread); try { boost::this_thread::sleep(timeout) } catch (const boost::thread_interrupted &e) { } ..but that would of course mean a new thread each time and I don't think it'll work. Looks like I'm gonna have to find another way. Cheers... Stephan

Just a small addition. Instead of sleep, you can use a condition variable and wait on it with timeout. So the if condition would be smth like: if(!timed_wait(cond, timeout)) t1.interrupt(); On Wed, Mar 4, 2009 at 3:30 PM, Ovanes Markarian wrote:

Stephan,

what about that:

On Wed, Mar 4, 2009 at 3:20 PM, Stephan Menzel wrote:

...

like this (pseudo):

void readthread() { try

{

...

// go into blocking read sock.sync_receive_from(...);

// signal successful read } catch(boost::thread_interrupted const& e) { //handle interruption }

...

}

original thread:

... thread t1(readthread); boost::this_thread::sleep(timeout);

if(/*not signaled successful read*/) t1.interrupt();

Regards, Ovanes

Stephan, I agree with you about timeout parameter. I might try tonight to code this behavior as work to be sure, that I did not suggest smth. completely out of scope. Best Regards from Munich (to Munich I assume) Ovanes On Wed, Mar 4, 2009 at 5:51 PM, Stephan Menzel wrote:

Ovanes,

...

Just a small addition. Instead of sleep, you can use a condition variable and wait on it with timeout. So the if condition would be smth like:

if(!timed_wait(cond, timeout)) t1.interrupt();

Well, I just started to implement this and I still get some erratic behaviour. Also I think in order to be consistent this can't be modular enough. There's the condition variable as well as the mutex around it (one more to the one I already use to protect the socket) and the thread function that needs to be bound to this object. All feasable and yet way to much complexity within the app compared to socket.receive_from(buffer, timeout), which I just noticed as I am currently using the originally posted receive_with_timeout in 2 classes already. I don't think I want all that and the thread still needs to be created and paid for.

I think I'll look into io_service.post. When the object that socket belongs to is created I can start several threads and use them as a pool. Then I might just use a timer, kill the socket and reinstanciate it. I hope this will make the blocking read return. It shouldn't happen too often anyway. In addition I'll also prepare to post this as a bug report to asio. Frankly I tend to consider the absence of such functionality a bug. If you offer sync IO you gotta include it. Don't get me wrong, asio is a phantastic lib but this needs to be done. IMHO either by including it or by removing sync IO entirely. Workarounds are not a solution.

Cheers...

Stephan

On Wed, Mar 4, 2009 at 11:23 AM, Igor R wrote:

...

Asio or Boost::Threads simply ignore each other and nowhere in the docs of asio is stated smth about boost::threads, but as it seems asio socket when it waits for input is in such an interruption point (may be it uses boost::threads internally)

Are you sure asio launches threads, besides the ones you supplied for io_service::run()?

No, that was not my point. If you use a socket from multiple threads and read data from it, socket blocks waiting for input. My point was, that this blocking wait is recognized by boost::thread lib as a valid interruption point. And my suggestion would be to state in the docs of Asio that synchronous wait operation is a valid interruption point for boost::thread. Sorry for misleading words. Therefore interrupting the thread should interrupt the synchronous wait.