Bug 220916

Summary: Synchronous messages cannot be answered with different type of encoder
Product: WebKit Reporter: Kimmo Kinnunen <kkinnunen>
Component: WebKit2Assignee: Kimmo Kinnunen <kkinnunen>
Status: RESOLVED INVALID    
Severity: Normal CC: eric.carlson, ews-watchlist, glenn, jer.noble, philipj, sergio, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Local Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch ews-feeder: commit-queue-

Kimmo Kinnunen
Reported 2021-01-25 04:27:35 PST
Synchronous messages cannot be answered with different type of encoder Current generated message handler has a special case for async messages and a special case for synchronous messages. The synchronous messages message handler signature is (Connection& connection, Decoder& decoder, Encoder& replyEncoder). This is inconvenient for planned WebGL IPC "stream" feature. In the "stream" use-case, most of the sync messages would come in the same way as async messages, via SHM memory buffer. The reply should go to the SHM memory buffer too, with the help of stream-specific encoder. Since the stream-specific encoder is not IPC::Encoder, current generated message handlers cannot support this. A solution could be to move the sync reply id to the end of the message payload, so that the message handling of async and sync messages can be unified.
Attachments
Patch (192.74 KB, patch)
2021-01-25 04:52 PST, Kimmo Kinnunen
no flags
Patch (127.57 KB, patch)
2021-01-25 04:57 PST, Kimmo Kinnunen
ews-feeder: commit-queue-
Kimmo Kinnunen
Comment 1 2021-01-25 04:52:38 PST
Kimmo Kinnunen
Comment 2 2021-01-25 04:57:53 PST
Radar WebKit Bug Importer
Comment 3 2021-02-01 04:28:13 PST
Kimmo Kinnunen
Comment 4 2021-02-25 04:03:23 PST
This is probably not needed. Currently the handleMessage function can dig out the sync reply id for the streams. Marking this as not blocking webglgpup and configuration changed.
Note You need to log in before you can comment on or make changes to this bug.