Jason Duell
2010-04-21 09:42:35 UTC
So when we launched IPDL, we were planning to limit the "rpc" semantic
for messages to just plugins. But now CPOW is using them, and it's
having fairly significant side-effects on how necko (at least) must be
coded.
Specifically: the necko HTTP protocol used to be able to rely on all
of its messages being delivered serially, i.e., first OnStartRequest,
then OnDataAvailable, then OnStopRequest. But now that code in the
DOM is using rpc messages, OnDataAvailable and/or OnStopRequest can
now be dispatched *during* RecvOnStartRequest. In other words, my
code now needs to be re-entrant, because some other protocol is using
rpc messages while my msgs are being dispatched.
To handle this, we're going to have to effectively buffer all incoming
messages in the HTTP IPDL protocol when they arrive, and then ensure
they're dispatched serially. This isn't rocket science, but it makes
the code more complicated, and probably more error prone. It makes
IPDL a lot less intuitive and convenient to use.
Is this just the way things are going to have to be? Does CPOW need
to use rpc? Is there no way we can isolate the effect of using rpc in
one protocol causing reentrant message dispatch in another? Cjones
tells me this would relax IPDL's global in-order delivery, but for
necko at least, I don't think we care about ordering versus other
protocol's msgs.
I'd like to get a clear answer on what our design point is here; I've
already got a patch to review that implements some re-entrancy
avoidance glorp, and want to know if this is indeed the road we're
going down. For details see
https://bugzilla.mozilla.org/show_bug.cgi?id=559200
for messages to just plugins. But now CPOW is using them, and it's
having fairly significant side-effects on how necko (at least) must be
coded.
Specifically: the necko HTTP protocol used to be able to rely on all
of its messages being delivered serially, i.e., first OnStartRequest,
then OnDataAvailable, then OnStopRequest. But now that code in the
DOM is using rpc messages, OnDataAvailable and/or OnStopRequest can
now be dispatched *during* RecvOnStartRequest. In other words, my
code now needs to be re-entrant, because some other protocol is using
rpc messages while my msgs are being dispatched.
To handle this, we're going to have to effectively buffer all incoming
messages in the HTTP IPDL protocol when they arrive, and then ensure
they're dispatched serially. This isn't rocket science, but it makes
the code more complicated, and probably more error prone. It makes
IPDL a lot less intuitive and convenient to use.
Is this just the way things are going to have to be? Does CPOW need
to use rpc? Is there no way we can isolate the effect of using rpc in
one protocol causing reentrant message dispatch in another? Cjones
tells me this would relax IPDL's global in-order delivery, but for
necko at least, I don't think we care about ordering versus other
protocol's msgs.
I'd like to get a clear answer on what our design point is here; I've
already got a patch to review that implements some re-entrancy
avoidance glorp, and want to know if this is indeed the road we're
going down. For details see
https://bugzilla.mozilla.org/show_bug.cgi?id=559200