asio forcing the use of handlers?
I am just about to find out how I could make use of the asio library, and am wondering if async io also can be done without using handler functions. I recognize that it is possible to use it in a blocked manner as follows: assuming we have an open socket: sock read(sock, buf); ... use the buffer contents ... Now I am wondering if I could also accomplish something like: cp = async_read(sock, buf); ... do something useful ... cp.wait(); .. use the buffer contents ... Thank you, Roland aka speedsnail
Roland Schwarz wrote:
I am just about to find out how I could make use of the asio library, and am wondering if async io also can be done without using handler functions.
I recognize that it is possible to use it in a blocked manner as follows:
assuming we have an open socket: sock
read(sock, buf); ... use the buffer contents ...
Now I am wondering if I could also accomplish something like:
cp = async_read(sock, buf); ... do something useful ... cp.wait(); .. use the buffer contents ...
Since handlers are just function objects you can use them to do pretty much anything, such as signalling your "cp" variable that the operation has completed. For example, see the sample code at the bottom of this posting: http://article.gmane.org/gmane.comp.lib.boost.devel/155402 Cheers, Chris
Christopher Kohlhoff wrote:
Since handlers are just function objects you can use them to do pretty much anything, such as signalling your "cp" variable that the operation has completed.
Ah, yes. I see.
For example, see the sample code at the bottom of this posting:
Thank you for the pointer. Roland aka speedsnail
Christopher Kohlhoff wrote:
I was traveling along this post, but now have another question: While my thread is waiting in the futures: T get() const { boost::mutex::scoped_lock lock(mutex_); while (!value_.get() && !exception_.get()) condition_.wait(lock); if (exception_.get()) exception_->raise(); return *value_; } it will not react to a io_service_.stop(); request. While I do understand why this is so, I wonder if there is a way to let the future also check for the demuxers stop flag and exit the wait by possibly throwing an error? Roland aka speedsnail
Roland Schwarz wrote:
Christopher Kohlhoff wrote:
I was traveling along this post, but now have another question:
While my thread is waiting in the futures:
T get() const { boost::mutex::scoped_lock lock(mutex_); while (!value_.get() && !exception_.get()) condition_.wait(lock); if (exception_.get()) exception_->raise(); return *value_; }
it will not react to a io_service_.stop(); request.
While I do understand why this is so, I wonder if there is a way to let the future also check for the demuxers stop flag and exit the wait by possibly throwing an error?
A stop() may only be a temporary condition for the io_service. You can subsequently reset the io_service and call run() again. I.e. the stopping of the io_service is a separate issue to whether the future is ultimately fulfilled. It might be more appropriate to use the destruction of the io_service object, since the io_service destructor cleans up all unfinished handler objects. If the handlers in turn hold the associated promise objects then the destruction of all promises can be used to indicate that the future has been abandoned. Cheers, Chris
participants (2)
-
Christopher Kohlhoff -
Roland Schwarz