Re: Test framework; and what should be in 1.1.0

[David Sugar]

There are cases when even on GNU/Linux systems that you might want to use pth 
rather than native threading, depending on your applications actual needs, so 
I thought it might be useful to do both together and select at link time 
(hence, the idea of ccpth2 as an alternate link to ccgnu2).    But yes, pth 
offers threading "emulation" on many platforms which do not have threading, 
and so would provide a foundation for using Common C++ for common application 
designs that then still port to those systems.  Whether we support pth and 
native threading together on one platform is however less important than that 
we at least support pth as an option (along with current posix and win32) in 
general for porting to those other platforms.

On Friday 03 January 2003 09:59, Albert Strasheim wrote:
> Hello,
>
> On Fri, 03 Jan 2003, Albert Strasheim wrote:
> > > Seems you want to provide a Thread class implemented on top of Pth?
> > > Isn't the pthread_* code always going to be inferior to this
> > > implementation?
> >
> > I am a bit mistaken here. Seems Pth uses the exact same function names,
> > etc., so the existing code remains unmodified? And you can decide if you
> > want to link against Pth, or just straight glibc (at least on Linux).
>
> You can get the exact same function names, if you use the backward
> compatible headers. The "normal" Pth functions are called pth_*.
>
> > And then on platforms with some weird thread library, you now get
> > existing code to compile by using Pth. Sweet.
>
> Generally you don't want to link against Pth on Linux? Pth doesn't
> contain any platform specific code, so it also doesn't support SMP and
> other nice bits and pieces. When the new thread code in glibc 2.3 and
> Linux 2.5/2.6 hits town, you'll probably definately want to be linking
> against that instead of against Pth. But on other platforms you probably
> have no choice.
>
> Cheers,
>
> Albert
>
>
> _______________________________________________
> Bug-commoncpp mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-commoncpp