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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Apr 27 10:59:19 PDT 2022


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

Geoffrey Garen <ggaren at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ggaren at apple.com

--- Comment #5 from Geoffrey Garen <ggaren at apple.com> ---
> 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?

How do we prevent the deadline from creating frame latency?

> 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?

> - 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?

I think I see the theoretical benefit to server-side hysteresis, or at least to not doing count-based hysteresis (less error-prone, messages can't get lost forever); but I also see two potential downsides:

(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 suppose it is an experimental question whether this cost / latency matters in practice.

(2) I believe the speed win of client-side hysteresis is already a known quantity.

-- 
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/5331c97f/attachment.htm>


More information about the webkit-unassigned mailing list