Re: deadlock in filesystem?

From: Ken Alverson (yg-boost-users_at_[hidden])
Date: 2003-07-09 15:51:41

"Russell Hind" <yg-boost-users_at_[hidden]> wrote in message
news:be0sl3$uln$1_at_main.gmane.org...
> When you build, I use (for borland)
>
> bjam -sTOOLS="borland" -sBUILD="<threading>multi"
>
> or something like that, haven't done it since the 1.30.0 release.  It
> definitely defaults to single threaded for borland for all libraries bar
>   boost::thread

Thanks, it took a couple tries and a few reads through the bjam documentation
before it clicked, but it seems to be working now (though I get a couple build
errors, mostly on the test directories).  I ended up with:

bjam -sTOOLS="vc7" -sBUILD="debug release <runtime-link>static
<threading>multi"

I have one final question.  I am using the threading dll, statically linked
with the multithreaded runtime.  My program (and the boost filesystem lib,
which I statically link against) is also statically linked with the
multithreaded runtime.  This means there are two instances of the static
runtime, one shared by my program and the filesystem, and one used by the
threading library.

Now, I know there are perils to having more than one copy of the runtime -
notably if memory allocated in one runtime is freed by a different runtime.
My question is whether it is safe to use the threading library linked in this
way.  I can't link against the dynamic runtime because I have to assume it is
not present, but I can't link the threading library statically since it isn't
designed to be built statically.

If not, is there a preferred solution?

Ken