From: Acosta, Mark W [Magic Earth LLC] (acostmw++at++texaco.com)
Date: 06/28/2000 13:09:51
Allan,
So is it just sproc that causes the problem with pthreads? Is
redefining sproc in terms of pthreads, as Ran described, a safe way to allow
using pthreads in Performer? I tried using Ran's definition of sproc in
terms of pthreads and my applications seems to lock up with or without it. I
do use sproc and pfQueues in my application.
Mark Acosta
Magic Earth LLC
-----Original Message-----
From: Allan Schaffer
To: rany++at++rtset.com; ross::barna
Cc: Acosta, Mark W [Magic Earth LLC]; 'info-performer++at++sgi.com '
Sent: 6/28/00 11:58 AM
Subject: Re: pthreads and Performer
On Jun 27, 10:55pm, Ran Yakir wrote:
>
> 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.
Ran is correct. Performer's general MP model (APP_CULL_DRAW
+ ISECT + COMPUTE + DBASE + X Input) uses fork(). There are a few
places in the library where we use sproc():
1. pfQueue's (used by pfCliptextures, paging ASD, etc)
2. "Threaded" per-channel CULL modes
3. LPOINT process is sproc'd from the DRAW
I'm sure there are others, these are just what came to mind.
As an aside, moving all uses of sproc() over to pthreads is one of
the things we're planning for a future-future release.
Allan
-- Allan Schaffer allan++at++sgi.com Silicon Graphics http://reality.sgi.com/allan
This archive was generated by hypermail 2b29 : Wed Jun 28 2000 - 13:11:52 PDT