Using ipc::Shmem causes unbounded shmem use growth until e.g. a Worker
yields to the event loop. If a Worker never yields, Shmems sent to WebGLParent
are never released.
Specifically the manager (PCanvasManager) for WebGLParent calls
DestroySharedMemory, which sends/enqueues for WebGLChild's manager a
matching call to ShmemDestroyed. However, while WebGLChild refuses to spin its
event loop (such as a no-return WASM Worker), the ShmemDestroyed events
will just pile up. Closing e.g. the tab frees the shmems, but they accumulate
unbounded until the Worker yields to the event loop.
This is true for other users of ipc::Shmem (or RaiiShmem) as well, but
entrypoints other than DispatchCommands are rarer and can be handled
later similarly.
Differential Revision: https://phabricator.services.mozilla.com/D162946
Using ipc::Shmem causes unbounded shmem use growth until e.g. a Worker
yields to the event loop. If a Worker never yields, Shmems sent to WebGLParent
are never released.
Specifically the manager (PCanvasManager) for WebGLParent calls
DestroySharedMemory, which sends/enqueues for WebGLChild's manager a
matching call to ShmemDestroyed. However, while WebGLChild refuses to spin its
event loop (such as a no-return WASM Worker), the ShmemDestroyed events
will just pile up. Closing e.g. the tab frees the shmems, but they accumulate
unbounded until the Worker yields to the event loop.
This is true for other users of ipc::Shmem (or RaiiShmem) as well, but
entrypoints other than DispatchCommands are rarer and can be handled
later similarly.
Differential Revision: https://phabricator.services.mozilla.com/D162946
Using the Shmem after our actor has lost IPC capability (say, because the other endpoint crashed) will cause the content process to also crash. ActorDestroy is where we detect that condition.
Differential Revision: https://phabricator.services.mozilla.com/D87352
* Use clearer pref names.
* Default (and only support) IPDL dispatching.
* Make DispatchCommands async-only.
* Sync ipdl command per sync webgl entrypoint.
* Eat the boilerplate cost, since there's not too many.
* Run SerializedSize off same path as Serialize.
* All shmem uploads go through normal DispatchCommands.
* Defer pruning of dead code for now so we can iterate quickly.
* Use Read/Write(begin,end) instead of (begin,size).
* This would have prevented a bug where we read/wrote N*sizeof(T)*sizeof(T).
Differential Revision: https://phabricator.services.mozilla.com/D81495
Implements LookupSharedMemory and AllocShmem in ProducerConsumerQueue (and fixes a few minor build issues). To be used in construction of a ProducerConsumerQueue, an actor has to subclass IPcqActor.
Differential Revision: https://phabricator.services.mozilla.com/D74974
IpdlQueue currently sends an async Ipdl message for every async WebGL call. This is a lot of overhead. This patch buffers those calls so that they can be send in large batches when either a synchronous call happens or the client calls FlushAsyncCache. The commands are then sent and processed in-order.
Differential Revision: https://phabricator.services.mozilla.com/D72047
IpdlQueue currently sends an async Ipdl message for every async WebGL call. This is a lot of overhead. This patch buffers those calls so that they can be send in large batches when either a synchronous call happens or the client calls FlushAsyncCache. The commands are then sent and processed in-order.
Differential Revision: https://phabricator.services.mozilla.com/D72047
IpdlQueue currently sends an async Ipdl message for every async WebGL call. This is a lot of overhead. This patch buffers those calls so that they can be send in large batches when either a synchronous call happens or the client calls FlushAsyncCache. The commands are then sent and processed in-order.
Differential Revision: https://phabricator.services.mozilla.com/D72047
Adds IpdlQueue capability to PWebGL actors. The WebGLChild, used in content processes, implements SyncProducerActor and AsyncConsumerActor because it sends (sync and async) messages and receives responses to them that it reads as async messages. The WebGLParent, used in the compositor process, is a SyncConsumerActor and AsyncProducerActor for dual reasons.
Differential Revision: https://phabricator.services.mozilla.com/D68264
Adds IpdlQueue capability to PWebGL actors. The WebGLChild, used in content processes, implements SyncProducerActor and AsyncConsumerActor because it sends (sync and async) messages and receives responses to them that it reads as async messages. The WebGLParent, used in the compositor process, is a SyncConsumerActor and AsyncProducerActor for dual reasons.
Differential Revision: https://phabricator.services.mozilla.com/D68264
* Context loss using RAII
* Move Program reflection Client-side
Depends on D54018
Differential Revision: https://phabricator.services.mozilla.com/D54019
--HG--
extra : moz-landing-system : lando
Splits WebGLContext into ClientWebGLContext and HostWebGLContext. The Client enables the JS-control of a WebGL context in a content procecss while the Host executes the WebGL graphics operations (via a WebGLContext that maintains much of the existing code) in the compositor process. At this point, the cross-process behavior is disabled -- this series of patches is an incremental step toward that final goal.
Differential Revision: https://phabricator.services.mozilla.com/D54018
--HG--
extra : moz-landing-system : lando
Kelsey Gilbert
Marian-Vasile Laza
Jim Blandy
Jeff Gilbert
Sylvestre Ledru
Butkovits Atila
David Parks
Razvan Maries
Narcis Beleuzu
Daniel Varga
David Parks