Subject: Re: [boost] [threads] making parts of Boost.Threads header-only
From: Anthony Williams (anthony.ajw_at_[hidden])
Date: 2009-04-07 16:55:23
Emil Dotchevski <emildotchevski_at_[hidden]> writes:
> On Tue, Apr 7, 2009 at 8:57 AM, Anthony Williams <anthony.ajw_at_[hidden]> wrote:
>> joaquin_at_[hidden] writes:
>>> Looks like a sensible part of Boost.Threads, namely that
>>> dealing with mutexes and locks, would be header-only
>>> but for its relying on boost/thread/exceptions.hpp, whose
>>> implementation is located at /libs/thread/*/exceptions.cpp.
>>> Given that this .cpp mostly consists of extremely simple
>>> definitions (as simple as do-nothing functions in many cases),
>>> would it make sense to move this to inline definitions in
>>> boost/thread/exceptions.hpp thus making mutexes and locks
>>> header-only? This would greatly enhance the appeal of this
>>> part of Boost.Threads, as having to link a separate module
>>> is a considerable burden.
>> That seems sensible.
> I am against such a move. Boost Threads requires linking for other
> features which makes it one of the few libraries in Boost that can be
> properly designed to avoid unnecessary physical coupling. Unless
> something is proven to cause performance problems it should not be
> inlined, regardless of how simple it is.
Wow, that's a hard line you've drawn there. I'm not sure I agree. The
only reason this matters is if you're going to be changing the
implementation and don't want to recompile the code that uses the
header. For boost users, the implementation only changes if they change
boost versions, and in that case I would expect people to recompile
anyway --- I wouldn't trust something compiled against boost 1.37 to
link against a 1.38 lib, for example.
In any case, after further thought I remembered the reason I didn't do
this before. If the exceptions are header-only then they cannot be
thrown from a DLL and caught outside the DLL, since the type-ids won't
match. This would mean that any exceptions thrown by the DLL version of
boost.thread wouldn't be able to be caught in user code other than by
catching std::exception or with catch(...). This is the case for
MSVC/Windows anyway --- I'm not sure about other compilers/platforms.
I could change the code so that if you're linking against the static
library then the exception functions are inline, since they can't be
thrown across DLL boundaries anyway in this case. That would mean that
if you were static linking against boost.thread then you wouldn't
actually need the lib in some cases (e.g. if all you used was
-- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk