Boost Asio io_service as global?
Hi all, I am just beginning to learn how to use Boost Asio in a multithreaded environment, and one thing struck me when looking at the various examples. I have not been able to find an answer to this in the documentation, but in case it is explained somewhere that I've missed I apologize in advance. Taking the asynchronous echo server as my base I am writing a multithreaded server that handles connections in a thread pool. My question is simply, why is the io_service object always passed around between class instances as a reference in the constructor? Why can one not store it as a global variable? I cannot see how this makes a difference, and a global seems to make things a lot easier. Is there a particular reason why I should not do this? Thanks in advance for any help. Kind regards, Philip Bennefall
your question is not relevant to boost::asio. You question is a design question: Should a frequent-accessed variable being global? My taste to your question is: I don't like global variable, so I would like to pass the reference around. jinqiang On Wed, Jul 20, 2011 at 11:23 AM, Philip Bennefall <philip@blastbay.com>wrote:
Hi all,
I am just beginning to learn how to use Boost Asio in a multithreaded environment, and one thing struck me when looking at the various examples. I have not been able to find an answer to this in the documentation, but in case it is explained somewhere that I've missed I apologize in advance.
Taking the asynchronous echo server as my base I am writing a multithreaded server that handles connections in a thread pool. My question is simply, why is the io_service object always passed around between class instances as a reference in the constructor? Why can one not store it as a global variable? I cannot see how this makes a difference, and a global seems to make things a lot easier. Is there a particular reason why I should not do this?
Thanks in advance for any help.
Kind regards,
Philip Bennefall _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
My question is relevant to Boost Asio in the sense that I was wondering as to whether there are any specific reasons not to make the io_service object in particular, global. If this is not the case, which is to say no special reasons not to make io_service in particular global, then you are right; it is a design question and I then have nothing further to enquire about. Kind regards, Philip Bennefall ----- Original Message ----- From: "Jinqiang Zhang" <jasonzha@gmail.com> To: <boost@lists.boost.org> Sent: Wednesday, July 20, 2011 5:00 AM Subject: Re: [boost] Boost Asio io_service as global? your question is not relevant to boost::asio. You question is a design question: Should a frequent-accessed variable being global? My taste to your question is: I don't like global variable, so I would like to pass the reference around. jinqiang
Philip Bennefall wrote: Please don't top post.
My question is relevant to Boost Asio in the sense that I was wondering as to whether there are any specific reasons not to make the io_service object in particular, global.
A program may well use multiple io_service objects, so creating just one is a degenerate case, but the API must account for the general case. If you use just one, making it a global or local to main(), for instance, is a matter of choice. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
participants (3)
-
Jinqiang Zhang -
Philip Bennefall -
Stewart, Robert