Date: 2001-06-05 14:53:44
--- In boost_at_y..., "Ken shaw" <ken_at_c...> wrote:
> ----- Original Message -----
> From: <williamkempf_at_h...>
> To: <boost_at_y...>
> Sent: Tuesday, June 05, 2001 12:13 PM
> Subject: [boost] Re: Boost Build System
> > --- In boost_at_y..., Gary Powell <Gary.Powell_at_s...> wrote:
> > >
> > > Most games are multi-threaded.
> > Most applications are not games ;). I'm not suggesting that any
> > library in Boost should not support building in multi-thread mode,
> > only that the default for <threading> be single.
> > > At a minimum the sound buffer for the music
> > > needs to run in its own thread or the music breaks up when the
> > scene gets
> > > texture rich.
> > >
> > > (Also due to the known errors in the single threaded MSVC
> > libraries, we
> > > always link the multithreaded ones. A dumb reason to do so, but
> > do what
> > > works and ship it.)
> > I've never run into a bug in the single threaded msvcrt that
> > also exist in the multi threaded msvcrt. What bugs are these?
> Don't know if really bugs per se but try passing STL objects
> functions without using the multithreaded libraries. Your code will
> bizarre and perverse fashion. This is a well known problem and
> the fact that different DLL's being used by the same application
> nearly seperate threads and code that is not at least reasonably
> kills it. In particular reference counting and other sorts of
> get hopelessly messed up.
The STL that ships with VC++ by and large can't be used in this
fashion whether or not you link against the multi threaded msvcrt.
DLLs have nothing to do with threads... they are not "very nearly
seperate threads" as you suggest here. However, static data can and
does create problems here the same as it does for multiple threads,
but for different reasons.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk