|
Boost Users : |
Subject: Re: [Boost-users] Fw: boost::asio
From: Lars Viklund (zao_at_[hidden])
Date: 2014-07-13 08:52:28
On Sun, Jul 13, 2014 at 08:11:23PM +0800, imran sheikh wrote:
> hi ,
>
> but if i am not using ioservice.reset() in the while loop then second time the threads are not executing properly.
> so please give me a strong running solution .i need immediately this one.
Hi there,
You appear to be missing some knowledge about how the operations on an
io_service fits together.
When you post a handler to an io_service, it will (eventually) run on
any thread that happens to do any of run(), run_one(), poll(),
poll_one().
The io_service will be in the running state as long as there exists
'work', operations in progress (like send/recv), or posted handlers in
queue.
Important here is that if the io_service runs out of things to do, it
finishes and returns from the run() functions.
The typical lifecycle of an io_service are:
== Setup ==
* prepare and post operations to it;
* construct instances of 'work' to artificially keep it alive;
* run one or more run()/run_one()/poll()/poll_one() somewhere.
== Runtime ==
* do things with devices, timers, post handlers, etc.
== Teardown ==
* destroy any artifical 'work' objects that you use to keep it running;
* stop posting more operations and handlers to it, so it runs out;
* optionally wait for it and any worker threads to finish.
For the scenario of a thread pool that runs posted handlers; the typical
approach is:
* make control 'work';
* create N threads, running run();
* post handlers until bored;
* destroy control 'work';
* join all N threads.
The reset() function shall only be called after the io_service is
stopped and you wish to eventually re-start it [1]. It's an error to
call reset() while you're run()ing.
[1] http://www.boost.org/doc/libs/1_55_0/doc/html/boost_asio/reference/io_service/reset.html
-- Lars Viklund | zao_at_[hidden]
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net