To what extend should we consider the fast producer/slow consumer problem?

[Mounir Lamouri]

A while ago we decided to deprecate the Client model for a
callback-based pattern to prevent Client not being able to handle the
fast paced messages. In that case, the message was coming from a mojo
service and the Client had to consume it.

I have been reviewing a CL today [1] where the relationship is reverted:
the client is sending messages to a mojo service. The CL author decided
to throttle the message flow to prevent the fast producer/slow consumer
problem in that situation.
However, it seems to me that we shouldn't try to solve it in that
situation because it makes the code way more complex (need to keep a
queue of messages which has to be reverted, otherwise no messages will
ever be sent) and it doesn't help any security or stability regarding
the service (a compromised client could bypass the throttling). In
addition, a page trying to call .send() in a loop will be able to "kill"
the renderer anyway.

Do you have any thoughts about this?

[1] https://codereview.chromium.org/1037483003

Cheers,
-- Mounir

[Darin Fisher]

This throttling makes sense given that the service just pushes the SendStringMessage parameters onto another queue (delegate_->SendStringMessage). It is unfortunate complexity indeed.

The MessagePipe is already a queue. If you could arrange for the service impl to not read messages from the pipe faster than it can fully process them, then the client would not need to worry about throttling messages at all. It would be nicer if the service impl could protect itself somehow instead.

We've talked about adding Suspend/Resume methods on mojo::Binding that service code could use to suspend further reads from the pipe, but it hasn't been implemented yet. Maybe now is the time.

-Darin

[Mounir Lamouri]

On Thu, 16 Apr 2015, at 15:04, Darin Fisher wrote:
> This throttling makes sense given that the service just pushes the
> SendStringMessage parameters onto another queue
> (delegate_->SendStringMessage). It is unfortunate complexity indeed.
>
> The MessagePipe is already a queue. If you could arrange for the service
> impl to not read messages from the pipe faster than it can fully process
> them, then the client would not need to worry about throttling messages
> at
> all. It would be nicer if the service impl could protect itself somehow
> instead.

What are the risks for the service?

> We've talked about adding Suspend/Resume methods on mojo::Binding that
> service code could use to suspend further reads from the pipe, but it
> hasn't been implemented yet. Maybe now is the time.

It would be great if such a protection could be built-in given that any
client could harm a service by spamming it, right?

-- Mounir