Re: pthread and perfly

New Message Reply Date view Thread view Subject view Author view

Phil Keslin (philk++at++cthulhu.engr.sgi.com)
Wed, 16 Dec 1998 16:20:53 -0800


Greg Harrison wrote:
>
> Phil Keslin wrote:
>
> >
> > There are no plans to move Performer to a pthreads base. To do so would
> > break just about every application out there. Pthreads assumes implicit
> > sharing and contains no support for the explicit shared memory model
> > adopted by Performer. We'd still have to use arenas, but as I already
> > stated, this doesn't work with pthreads.
> >
> > "Fixing" this would require a fundamental change in the way at least the
> > C library works for multi-threaded applications and the way
> > multi-threaded applications are scheduled by the kernel. This
> > incompatibility won't be fixed.
>
> I accept the inherent problems with changing the inner workings of Performer
> or trying to get them to peacefully co-exist with pthreads, but what about
> making Farenheight Scene Graph and its 'add-on modules' (that will
> eventually replace Performer) be pthreaded? If FSG is to be a joint MS-SGI
> standard this would appear to be a good/necessary thing, since MS is
> certainly not going to implement sproc. Anyone thought this one out already
> at SGI eng?

I think that the FSG is already pthreads aware. So yes, we have already
thought it through.

- Phil

-- 
Phil Keslin <philk++at++engr.sgi.com>

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Wed Dec 16 1998 - 16:20:56 PST

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.