Re: Simultaneous destructors

On 9/17/09 11:50 AM, Chris Jones wrote:

> There are two facets to the problem.  The first mainly applies to
> nominally stateless, inherently racy protocols like NPAPI.  The example
> you present with ~PBrowserStream forces a design decision: whether or
> not to allow destructor messages to race.  I would prefer to just
> disallow racy destructors; I think there's a workaround for the NPAPI
> (generally, crappy API) case.  The workaround is two-phase destruction.

I don't think this is specific to crappy APIs or destructors, *any* message
could race with the destructor, really. Let's say the parent always calls
the destructor. You still have potentially parent: ~PBrowserStream() racing
with any other allowable message sent by the child, e.g. NPN_RequestRead.

What about a perfectly async API such as networking streams, with a one-way
destructor:

async protocol PNecko {
parent:
  PChannel()
  ~PChannel();
}

async protocol PChannel {
child:
  DataAvailable();
};

Isn't is possible for DataAvailable to race with ~PChannel?

--BDS