Re: GNU Common C++ "2" 1.1, GNU pth, and NGPT

[David Sugar]

Native threads and pth have very different behaviors and characteristics,
and depending on what one is doing, it may at times be more desirable to
use one vs the other, so I don't think of it "shocking", but simply a
question of being able to choose application behavior :).  I think most
times people will want native threading, since that spreads over SMP
systems, even if it's more complex to debug.  One could then use pth to
prototype threaded application logic.  In some cases, scaling over
multiple CPU's is not important, and pth does have less overhead
processing sychronization objects.  Of course, there are also now pth
based thread libraries that also do use true process scheduling to enable
SMP....

On Wed, 13 Nov 2002, Federico Montesino Pouzols wrote:

> On Sat, Nov 09, 2002 at 09:59:27AM -0500, David Sugar wrote:
> > My thought on this is that GNU pth should be an alternate compilable 
> > build.  Normally one builds ccgnu2 which everything then is linked to.  In 
> > this scenario, an alternate ccpth2 would be created, and everything could 
> > alternately be linked to that.  This would allow one to have a choice of 
> > threading environment and characteristics (native, or portable) and to 
> > make that choice by which one is chosen at link time.
> > 
> 
>       I recall I have read there was the intention to make cc++ work
> well with pth. Having two threading environments selectable at link
> time would certainly be a shocking feature.
> 
> > my proposal is to have a seperate pth subdirectory (along with src and
> > win32), and have the pth subdirectory build a ccpth library, often out of
> > the same source files as were used for ccgnu2, but with a CCXX_PTH
> > defined.  Assuming the base classes offer no alignment variances (and this
> > will be done through the headers), ccext2 and other things should then be
> > linkable against either ccgnu2 or ccpth2, and an option could be added to
> > ccgnu2-config to request linkage and compile time options for ccpth rather
> > than for ccgnu.
> > 
> 
>       I think we should also add two exclusive symbols:
> COMMON_PORTABLE_THREADING and COMMON_NATIVE_THREADING. CCXX_PTH would
> fall whithin COMMON_PORTALE_THREADING.
> 
> > The curious question is what happens with platforms that have no native 
> > thread support at all, but do have a port of pth.  Should pth then become 
> > the ccgnu2 on those platforms?  
> > 
> 
>       I think it should, it is a very elegant solution.
>