From: Ran Yakir (rany++at++netvision.net.il)
Date: 06/27/2000 13:55:35
Actually, I think Performer is forking and not sprocing. You will encounter
problems only if you use a pfQueue, which uses sproc. Since pfQueue is used by
cliptextures, then cliptextures and pthreads are your problem. I've safely used
Performer with pthreads when cliptextures were not needed.
However, if you do need to use cliptextures and pthreads, I've made a hack that
enables it. You can download it from my web page
http://rtset.co.il/rany/downloads.html
This hack implements sprocsp (the function used by pfQueue) using pthreads, in
a transparent manner.
Good luck
Ran
ross::barna wrote:
> rules of thumb for pthreads + performer that seem to work for me:
>
> 1) sproc before fork
>
> performer sproc's, pthreads fork. make sure to
> spawn your performer proc's before your threads!
>
> 2) don't access performer data structure while pf is drawing
>
> use a read/write lock to make sure your threads don't
> mess with pfObjects while pfSync(), pfFrame()
> and pfDraw() are being called. the pthreads are readers
> and the fn that calls pfSync, frame and draw is the
> writer.
>
> -ross
>
> On Tue, 27 Jun 2000, Acosta, Mark W [Magic Earth LLC] wrote:
>
> > I recall that mixing pthreads and Performer was a bad thing. Is this still
> > true?
> >
> > Mark Acosta
> > Magic Earth LLC
> > -----------------------------------------------------------------------
> > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
> >
>
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2b29 : Tue Jun 27 2000 - 12:55:16 PDT