IPC Protocols: Difference between revisions

The PDL compiler will take as input a FooProtocol.pdl source and generate FooProtocolServer.h and FooProtocolClient.h C++ headers.  These headers will declare message types for the transport layer, declare protocol states, and define functions that take care of state transitions and invoke message handlers.  The headers will leave undefined the ''implementations'' of message handlers; these are up to mozilla code to provide.  (Perhaps through subclassing.)

Message handlers will be responsible for processing the received message (obviously) and also deciding which of the allowed states is transitioned to after processing.  The generated protocol header will enforce protocol safety here.  Lower-level enforcement of transport-layer properties, like not nesting asynchronous calls within synchronous handlers, can be enforced in a shared ProtocolBase class.  '''TODO''': should these kinds of properties be global, or defined in protocol specs? What are all these properties?  Deadlock avoidance is another, if we provide synchronous messages.

Protocol safety (only sending/receiving allowed messages from particular states) will be enforced by generating a finite-state machine in the protocol header, and checking sent/received messages against this state machine.

Very importantly, there will be an implicitly-defined ERROR state that occurs when an actor violates the protocol (or a type safety constraint).  How this is handled is very much open to discussion.

'''NOTE''': I think it's worthwhile leaving error detection on even in optimized builds.  It should be quite cheap compared to IPC overhead and will likely allow us to avoid security-related bugs.

 

An ''actor'' will just be an instance of a protocol server or client class.  We need some way of addressing particular actors across threads and processes.  Hopefully the chromium IPC code already supports this.  Also, we can easily support process-to-process and thread-to-thread communication over these protocols.  The latter would be very useful for debugging, and also useful for writing threaded code that avoids shared memory as much as possible (even when we have multiple processes we will still have multiple threads).

 

I '''do not''' think that protocol instances should be thread safe (in the usual shared-memory sense).  We should use these protocols to avoid this kind of threaded code, whether in-process or out-of-process.