This is the mail archive of the
libstdc++@sources.redhat.com
mailing list for the libstdc++ project.
Re: [PATCH] Add BeOS support for libstdc++-v3
- To: Gabriel Dos Reis <gdr at codesourcery dot com>
- Subject: Re: [PATCH] Add BeOS support for libstdc++-v3
- From: Phil Edwards <pedwards at disaster dot jaj dot com>
- Date: Tue, 21 Nov 2000 18:20:01 -0500
- Cc: Daniel Berlin <dan at www dot cgsoftware dot com>, gcc-patches at gcc dot gnu dot org, libstdc++ at sources dot redhat dot com
- References: <Pine.LNX.4.10.10011211102240.9416-300000@www.cgsoftware.com> <20001121173437.A16465@disaster.jaj.com> <flhf51ylg5.fsf@sel.cmla.ens-cachan.fr>
On Wed, Nov 22, 2000 at 12:06:18AM +0100, Gabriel Dos Reis wrote:
> Phil Edwards <pedwards@disaster.jaj.com> writes:
> |
> | means that BeOS-native threads will /always/ be used. Currently we default
> | to no threads on all platforms, and the installer must request them (e.g.,
> | "--enable-threads=beos"). This patch means that BeOS alone would be in
> | the reverse situation.
>
> Is there any reason we should default to 'no threads' on all plateforms?
Not in the future. When I wrote that "this may be the way we're heading
anyhow," I was thinking that in an ideal world, each platform would default
to whichever threading model fit the best. Asking for single/no threads
would be a debugging technique, or for special-purpose builds. Or YAMC[*].
Currently, of course, we default to no threads because we have almost zero
thread support in the library. :-|
Phil
[*] Yet Another Multilib Configuration.
--
pedwards at disaster dot jaj dot com | pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools. Fools are protected by more capable fools.