id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
10174,call_stack not working when building asio as shared module on windows,wberrier@…,chris_kohlhoff,"The call_stack is not working when building asio as shared module on windows.

Also, the call_stack doesn't work on windows when using asio as header only and loading a dll at runtime (ie: LoadLibrary) which is also using asio as header only.

See and run the attached test case that demonstrates the problem in the following scenario:

* MSVC 2010 Express SP1 32bit (I'm guessing it's an issue on other compilers as well, but this is what I was using)
* build asio as a shared library according to instructions for ""separate compilation"" [ 1 ]
* build and run the test case, where all cases should say ""PASS""

Now, I know the documentation says that .dispatch() *may* execute the handler right away (see discussion[ 2 ] on mailing list), so it's officially not a bug.

BUT, I noticed that ""strand.running_in_this_thread()"" worked.  That's what clued me in that call_stack was working as expected for running_in_this_thread(), but not for dispatch().

It appears that the issue is with static storage for boost::asio::detail::callstack::top_ .

It appears that two copies of this static storage item are being referenced: one from the .exe file, and one from the .dll (both of which include the asio headers).

It looks like the reason ""running_in_this_thread()"" works is because it calls callstack<>::contains() from an .ipp file, which is included in the .dll so it references top_ from the .dll.

In the case of using asio as header only, not running any asio code from a .dll, the issue is non-existent.  There is no confusion as to which top_ variable to use.

See the attached patch to asio/detail/impl/strand_service.hpp that fixes strand.dispatch() by calling ""running_in_this_thread()"".  That forces the reference of top_ from the .dll instead of the reference from the .exe that's linked against the asio dll or another .dll that includes asio headers.

Possible fixes for this:
1. put the definition of top_ in an .ipp file to include in the boost asio .dll so there's only one symbol for it.
2. put all usages of call_stack in .ipp files (similar to the attached patch) so there's no confusion about the symbol (ugly and error prone, since it would have to be done for all use cases)

It should be noted that in order for call_stack to work across a dll boundary (ie: sharing io_service or strand between a .exe and .dll), asio *must* be built as a shared library.

Also, note that this only happens on Windows.  Doing the equivalent with .so files works in Linux (maybe by chance?  not sure...).

Not having this fix makes .dispatch() pretty much useless when using asio on windows with .dlls.

",Bugs,new,To Be Determined,asio,Boost 1.55.0,Problem,,windows dispatch,