Marcus Barnes (marcus++at++multigen.com)
Thu, 28 Aug 1997 12:50:05 -0700
> and will be freed if their count reaches 0.
^^^^^^^^^^^^^
I think you misread this here.
> A workaround for this bug is using pfMemory::checkDelete()
> instead of pfDelete() and everthing works like expected.
The short story is: pfDelete calls pfBuffer::checkDelete which ultimately
calls, or schedules calls to, pfMemory::destroy.
pfUpdatable's are scheduled via pfBuffer::pf_addDeletionUpdate and
pfMemory::destroy is invoked in the APP process by pfSync (at least three
pfFrame's later).
NOTE: I'm ignoring all the destructors and derived class operations that happen
in between these two end points.
> But what workaround exists for pfAsyncDelete(), which have the same
> bug as pfDelete()?
I don't think there is a bug.
> As I (k)now, pfDelete() uses pfBuffer::checkDelete(). What
> is the difference between pfBuffer::checkDelete() and
> pfMemory::checkDelete()?
pfBuffer::checkDelete's job is to (arrange to) delete pfMemory's in a MP safe
manner.
pfMemory::checkDelete's job is to (perhaps) delete pfMemory's while honoring
their reference counts.
Regards.
--
+ Marcus Barnes, Technical Staff mailto:marcus++at++multigen.com +
+ Multigen Inc. http://www.multigen.com +
+ 550 S. Winchester Blvd. phoneto:1-408-556-2654 +
+ Suite 500 San Jose CA 95128 faxto:1-408-261-4102 +
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:55:48 PDT