545923 - IPDL: Abolish "stateless" protocols

Status: RESOLVED WONTFIX

(Core :: IPC, defect)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

What we currently call "stateless" protocols really have at least two implicit states, ALIVE and DEAD.  The original plan was to shift the burden of dancing around stateless protocols onto IPDL-generated code, but a better approach (when we have |discard|) is to instead make protocols handle this themselves.  It's better documentation and keeps the generated C++ cleaner.

Comment 1

[Benjamin Smedberg]

I think this actually may be difficult with PPluginScriptableObject, because the state system that we hand-crafted for it doesn't really fit into the system. In the 'unprotected' state, an actor can have two messages: a 'protect' state sent by the remote side, or a __delete__ message sent by the local side. We know these won't race because they depend on the stack-frame state, but I don't think we have a way to represent this to IPDL.

Comment 2

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Why do we know they can't race?  What's the stack-frame state that prevents it?

Comment 3

[Benjamin Smedberg]

I'll describe in terms of browser objects held by the plugin:

When a browser object is passed to the plugin
* the browser side increments an internal "protection" counter
* Inside the RPC call, the plugin side may "protect" the object from destruction and make NPRuntime calls on it. It may then either keep a reference (in which case the actor will remain protected) or not.
* When the stack frame exits, the browser side un-increments the protection counter.
** If the plugin side has protected the object, it will continue to be "live" and the plugin may make calls on it.
** If the plugin has not protected the object, the browser will deallocate it

There are two basic states:

BROWSER_OBJECT_UNPROTECTED - browser may delete, or plugin may protect
BROWSER_OBJECT_PROTECTED - plugin may make NPRuntime calls or unprotect

In the BROWSER_OBJECT_UNPROTECTED state, whether the object is deleted or protected depends on the RPC call stack.

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

It seems like a workaround is to send a message that transitions from UNPROTECTED to DOOMED, from which only __delete__ may be sent.

Comment 5

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(In reply to comment #4)
> It seems like a workaround is to send a message that transitions from
> UNPROTECTED to DOOMED, from which only __delete__ may be sent.

Although I should say I would need to work this out with a real protocol to see what races arise.  This might need to be two phase.

Comment 6

[Andrew McCreight [:mccr8]]

All protocols are stateless now.