Re: [Boost-users] [asio] sync receive_from with timeout

Subject: Re: [Boost-users] [asio] sync receive_from with timeout
From: Ovanes Markarian (om_boost_at_[hidden])
Date: 2009-03-04 12:04:45

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 <stephan.menzel_at_gmx.eu>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
>