[Spirit] qi::parse at translation unit global scope?
I noticed this when I played around with wrapping qi::parse() in a parse() function that does some things before and after qi::parse(). My code had been calling qi::parse(), with the `qi::` namespace prefix, everywhere so I removed from a few calls and compiled before adding a parse() declaration. Lo and behold, compilation unexpectedly succeeded. I've reduced the behaviour in a minimalistic sample program (attached). I expect their to be *no* parse() function within the scope of main(). Can anyone clarify why the compiler has no trouble finding one and which one it finds? Adding a global scope operator to the call, i.e. saying ::parse(), does result in the expected compile error. Using Boost 1.46.1, gcc 4.6.2 on Debian wheezy. Thanks in advance, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962
On 1 February 2012 20:33, Olaf Meeuwissen <olaf.meeuwissen@avasys.jp> wrote:
I noticed this when I played around with wrapping qi::parse() in a parse() function that does some things before and after qi::parse().
My code had been calling qi::parse(), with the `qi::` namespace prefix, everywhere so I removed from a few calls and compiled before adding a parse() declaration. Lo and behold, compilation unexpectedly succeeded. I've reduced the behaviour in a minimalistic sample program (attached).
I expect their to be *no* parse() function within the scope of main(). Can anyone clarify why the compiler has no trouble finding one and which one it finds?
Adding a global scope operator to the call, i.e. saying ::parse(), does result in the expected compile error.
Using Boost 1.46.1, gcc 4.6.2 on Debian wheezy.
Thanks in advance, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
The compiler uses Argument Dependent Lookup (ADL) to determine which function to call. One of the parameters is qi::rule, so the compiler looks in that namespace for a matching parse function.
Our software runs on both linux and solaris platforms. Our threads use boost threads, and will sleep using boost::this_thread::sleep(millisec) On solaris we are using prstat to monitor the process and lightweight process details. Prstat allows one to see thread level detail by using the –Lm option (prstat -Lm -p pid) In this case a variety of information is output per thread (see prstat reference link at bottom of e-mail): for example system time (SYS), user time (USR), sleep time (SLP), and user lock time (LCK). The user lock time is time spent waiting by a thread for synchronization (protected) resources. Interestingly all of our threads show up with a high-level of user lock time. Wanting to understand this I spent time today isolating the user lock time to the call to boost::this_thread::sleep(1000). When our thread did nothing but wake up and go back to sleep for 1000 milliseconds the thread would show up with 100% LCK rather than 100% SLP. As an experiment I replaced the single call to boost::this::thread::sleep(1000) with a comparable call to nanosleep(). In this case the thread shows up as 100% SLP, rather than 100% LCK (and looks more like what I would have expected). Having read a bit more about the boost::this_thread::sleep I believe that this may be because the boost sleep implementation actually uses a mutex (synchronization object) and hence the thread really is waiting for a synchronization resource. I’ve come to the conclusion that this “100 % locked” indicator for our threads is not necessarily indicative of a problem, rather it is just an artifact of the boost::this_thread::sleep implementation. I’m still a bit queasy about this and would like some confirmation from the experts. Is the fact that our boost threads (when sleeping) show up as 100% locked rather than 100% sleeping a problem, or is it just an artifact of the boost thread implementation? ---------------------------------------------- As a point of reference pls see the following link, it talks to the LCK output of prstat. http://www.scalingbits.com/performance/prstat Please see the section labeled: prstat usage Scenario – Excessive Locking Thanks in advance for any insights in this regard. - This message is intended only for the addressee and may contain information that is company confidential or privileged. Any technical data in this message may be exported only in accordance with the U.S. International Traffic in Arms Regulations (22 CFR Parts 120-130) or the Export Administration Regulations (15 CFR Parts 730-774). Unauthorized use is strictly prohibited and may be unlawful. If you are not the intended recipient, or the person responsible for delivering to the intended recipient, you should not read, copy, disclose or otherwise use this message. If you have received this email in error, please delete it, and advise the sender immediately. -
Le 01/02/12 12:07, Sargrad, Dave a écrit :
Our software runs on both linux and solaris platforms. Our threads use boost threads, and will sleep using boost::this_thread::sleep(millisec)
<snip> Interestingly all of our threads show up with a high-level of user lock time. Wanting to understand this I spent time today isolating the user lock time to the call to boost::this_thread::sleep(1000).
When our thread did nothing but wake up and go back to sleep for 1000 milliseconds the thread would show up with 100% LCK rather than 100% SLP.
As an experiment I replaced the single call to boost::this::thread::sleep(1000) with a comparable call to nanosleep(). In this case the thread shows up as 100% SLP, rather than 100% LCK (and looks more like what I would have expected).
Having read a bit more about the boost::this_thread::sleep I believe that this may be because the boost sleep implementation actually uses a mutex (synchronization object) and hence the thread really is waiting for a synchronization resource.
I’ve come to the conclusion that this “100 % locked” indicator for our threads is not necessarily indicative of a problem, rather it is just an artifact of the boost::this_thread::sleep implementation.
I’m still a bit queasy about this and would like some confirmation from the experts. Is the fact that our boost threads (when sleeping) show up as 100% locked rather than 100% sleeping a problem, or is it just an artifact of the boost thread implementation? Hi,
I agree that it will be better if this_thread::sleep uses platform specifics that show your program is sleeping. I see however the code in libs/thread/src/pthread/thread.cpp void sleep(const system_time& st) ... # elif defined(BOOST_HAS_NANOSLEEP) timespec ts; to_timespec_duration(xt, ts); // nanosleep takes a timespec that is an offset, not // an absolute time. nanosleep(&ts, 0); which uses nanosleep when available. Could you check if BOOST_HAS_NANOSLEEP is defined on Solaris? Hint:Add an #error after the elif. Best, Vicente
Vitaly Budovski <vbudovski+news@gmail.com> writes:
On 1 February 2012 20:33, Olaf Meeuwissen <olaf.meeuwissen@avasys.jp> wrote:
I noticed this when I played around with wrapping qi::parse() in a parse() function that does some things before and after qi::parse().
My code had been calling qi::parse(), with the `qi::` namespace prefix, everywhere so I removed from a few calls and compiled before adding a parse() declaration. Lo and behold, compilation unexpectedly succeeded. I've reduced the behaviour in a minimalistic sample program (attached).
I expect their to be *no* parse() function within the scope of main(). Can anyone clarify why the compiler has no trouble finding one and which one it finds?
Adding a global scope operator to the call, i.e. saying ::parse(), does result in the expected compile error.
The compiler uses Argument Dependent Lookup (ADL) to determine which function to call. One of the parameters is qi::rule, so the compiler looks in that namespace for a matching parse function.
Thanks. For anyone who needs a bit more info on ADL, here's a pointer http://en.wikipedia.org/wiki/Argument_dependent_lookup Based on that, the compiler fails to find a matching class member function (doh, we're in main() ...) for the unqualified call to parse() and then starts looking in qi which is an alias for boost::spirit::qi and finds the parse() free function in that namespace. I see. Hope this helps, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962
participants (4)
-
Olaf Meeuwissen -
Sargrad, Dave -
Vicente J. Botet Escriba -
Vitaly Budovski