Re: pfDelete bug

New Message Reply Date view Thread view Subject view Author view

Marcus Barnes (marcus++at++multigen.com)
Tue, 2 Sep 1997 17:18:44 -0700


On Sep 1, 7:52pm, Axel Schmidt wrote:
> Hi Marcus:
>
> Thanks for your answer. I am afraid I was unable to state
> my problem sufficiently clear. So once again:

Your welcome :)

> As the test program from my last mail demonstrated,
> pfDelete doesn't have immediate effect on attribute arrays
> of a pfGeoSet.

Actually, it doesn't have immediate effect on the pfGeoSet. This is partly due
to the extra reference counting in your program. If I simply delete the
geode/geoset/coord without any extra pfRef's or pfDelete's the test output is
as follows:

before any deletion : geode-rc=0 gset-rc=1 coord-rc=1
after pfDelete(geode)==1 : gset-rc=0 coord-rc=1
after 1 pfFrame() : coord-rc=1 (should be 1)
after 2 pfFrame() : coord-rc=1 (should be 1)
after 3 pfFrame() : coord-rc=1 (should be 1)

... which shows MP safe deletion of your geode and it's children by pfDelete,
which is really pfBuffer::checkDelete. By changing the code to deal only with
the geoset and its coord array, the same basic behavior is seen (see below)

> Only the geoset reference count is
> decremented immediately, while the attr-array is
> decremented not before the 4th pfFrame call.

Performer classes that are derived from pfUpdatable delete themselves in an MP
safe manner at all times. pfBuffer appears to extend this safety to pfObject,
by calling pfMemory::IsOfType to decide how to delete the object.

> According to the manual page, this behaviour would be expected only for
> pfAsyncDelete.

The only real difference between pfAsyncDelete and pfDelete is that the former
may occur in the DBASE process ... asynchronously from the APP process.

> Thus, I suggest to clarify the behaviour of pfDelete in the manual page.

I agree that the subject needs further clarification by the pfTeam.

> Also, a reference to "pfMemory::checkDelete" for an immediate deletion
> of all children would be extermely helpful.

Don't rely on this because this is a virtual function whose exact behavior
changes. In many cases pfDelete and *::checkDelete will behave the same. For
example pfGeode::checkDelete() overrides pfMemory::checkDelete() to schedule
the deletion via pfBuffer::pf_addDeletionUpdate(), since a geode is a pfNode
and it's deletion needs to be MP safe.

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

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:55:51 PDT

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