[Webkit-unassigned] [Bug 231352] IPC should not have client side message hysteresis

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=231352

--- Comment #6 from Kimmo Kinnunen <kkinnunen at apple.com> ---
(In reply to Geoffrey Garen from comment #5)
> > When server runs out of messages, it waits with a deadline on the stream semaphore but does not set the "server is waiting flag".
> 
> Is there a point to waiting on the semaphore rather than just sleeping? If
> the "server is waiting flag" is not set, will anybody ever signal the
> semaphore?

Why *would* you sleep instead of sleeping by waiting on the semaphore? If the code is basically structured around "and then we wait on the semaphore", it's natural to sleep by waiting.

If there's multiple producers on the same semaphore they will signal the semaphore. In webgl, where there is one work queue per N contexts.

In case there's a sync message, we can signal the semaphore to immediately wake up the hysteresis-sleeping server. (Until the sync message is implemented via event link)

> How do we prevent the deadline from creating frame latency?

What do you mean *frame* latency?

There's latency for buffering the messages client side.
There's latency for buffering the messages server side.

> > To match the current hysteresis implementation, the wait time could be tuned to be roughly (current hysteresis item count * average time to produce 1 item).
> 
> How would this tuning account for hardware differences in average time to
> produce 1 item?

Are you asking concretely or are you pointing out philosophically the futileness of the "average time"?

Concretely I'd start with 100ns and build an (exponential?) increasing wait with few steps. And see how that behaves.

Futility aspect is the same for choosing N for client-side items as it is for choosing X ns for server-side wait. In other words, if 100 client-side items is selected, I can ask "how the selection of the 100 items account for hardware differences"?

> > - If prepareForDisplay() is buffered due to hysteresis, no frame gets displayed.
> > If we buffer FlushContext due to hysteresis, we never get the didFlush?
> 
> Does client-side hysteresis become viable if we simply have items like
> prepareForDisplay() and FlushContext carry a "terminate hysteresis and send
> immediately" flag with them?

prepareForDisplay has a result so that is marked already. It would be sent immediately.

FlushContext would have a result once the interface is moving away from display list type abstraction to normal "IPC function call" abstraction.

FlushContext currently would need such a flag, as there's ad hoc reply didFlushContext that is not part of the message system specification. Flags would indicate the intent, yes in this case this would help.

Similar case we have for FinalizeRenderingUpdate-didFinalizeRenderingUpdate.

We can add flags on top of special cases. The point being, how would an average programmer who doesn't care about the IPC understand that "unless you put flag QQ to your message, it may never get delivered". When you put it like that, it does not make much sense.

If you open any .messages.in interface, there's plenty of async messages that implicitly assume forward progress, as the intended side-effect is naturally expected to happen. Peppering the code-base with "SendOptions::ReallySendItNow" doesn't sound eloquent.. 

> (1) The server will always incur either extra cost or extra latency in
> discovering that the client has produced sufficient display list items,
> since doing so requires some kind of synchronization on shared memory,
> whereas it is virtually free for the client to discover that it has added
> display list items.

I don't understand the distinction between these:
A) The server sleeps 100ns because the client doesn't signal. That's 100ns latency.
B) The server sleeps 100ns because it didn't say client should signal. That's 100ns latency.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220427/356fb336/attachment-0001.htm>