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

[Federico Montesino Pouzols]

        Oh well, sorry, I should check some dictionary when writing
adjectives whose meaning I am not sure of :). With "shocking" I meant
great or extraordinary.

        Yes, pth will improve the performace of many applications, and
having the possibility to choose at link time is a extremely flexible
scheme. NGPT support is also a very interesting goal. We could start
to fill in COMMON_PORTABLE_THREADING with CCXX_PTH, and then add
CCXX_NGPT :).

On Wed, Nov 13, 2002 at 06:49:24PM -0500, David Sugar wrote:
> 
> 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.
> > 
>