Currently we have two conflicting goals for WorkerDebuggeRunnables sent to the parent: 1) We need to be able to throttle them, in particular if the debugger is running 2) Events posted to the parent should be delivered even if the worker is dying `WorkerRunnable` seems to be designed to always have a living `WorkerPrivate` even during `Run` on a non-worker thread. This design forced us to keep the worker alive through a `StrongWorkerRef` until the event is actually run. In case of a `postMessage` to the parent this should not be necessary, as the worker could well close immediately after having dispatched the message to the parent but before the parent actually run it. All the information needed to accept the message should be frozen at the moment of dispatch. This opens the question if we could have a `WorkerParentRunnable` base class that accounts for the differences between runnables meant to run on the worker and not, ensuring that we expect its WorkerPrivate to be alive only during `Dispatch` but not during `Run`, freezing all needed information during the dispatch.
Bug 1769913 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Currently we have two conflicting goals for `WorkerDebuggeRunnable`s sent to the parent: 1) We need to be able to throttle them, in particular if the debugger is running 2) Events posted to the parent should be delivered even if the worker is dying `WorkerRunnable` seems to be designed to always have a living `WorkerPrivate` even during `Run` on a non-worker thread. This design forced us to keep the worker alive through a `StrongWorkerRef` until the event is actually run. In case of a `postMessage` to the parent this should not be necessary, as the worker could well close immediately after having dispatched the message to the parent but before the parent actually run it. All the information needed to accept the message should be frozen at the moment of dispatch. This opens the question if we could have a `WorkerParentRunnable` base class that accounts for the differences between runnables meant to run on the worker and not, ensuring that we expect its WorkerPrivate to be alive only during `Dispatch` but not during `Run`, freezing all needed information during the dispatch.
Currently we have two conflicting goals for `WorkerDebuggeRunnable`s sent to the parent: 1) We need to be able to throttle them, in particular if the debugger is running 2) Events posted to the parent should be delivered even if the worker is dying `WorkerRunnable` seems to be designed to always have a living `WorkerPrivate` even during `Run` on a non-worker thread. This design forced us to keep the worker alive in `WorkerDebuggeeRunnable` through a `StrongWorkerRef` until the event is actually run. In case of a `postMessage` to the parent this should not be necessary, as the worker could well close immediately after having dispatched the message to the parent but before the parent actually run it. All the information needed to accept the message should be frozen at the moment of dispatch. This opens the question if we could have a `WorkerParentRunnable` base class that accounts for the differences between runnables meant to run on the worker and not, ensuring that we expect its WorkerPrivate to be alive only during `Dispatch` but not during `Run`, freezing all needed information during the dispatch.
Currently we have two conflicting goals for `WorkerDebuggeRunnable`s sent to the parent: 1) We need to be able to throttle them, in particular if the debugger is running 2) Events posted to the parent should be delivered even if the worker is dying `WorkerRunnable` seems to be designed to always have a living `WorkerPrivate` even during `Run` on a non-worker thread. This design forced us to keep the worker alive in `WorkerDebuggeeRunnable` through a `StrongWorkerRef` until the event is actually run. In case of a `postMessage` to the parent this should not be necessary, as the worker could well close immediately after having dispatched the message to the parent but before the parent actually run it. All the information needed to accept the message should be frozen at the moment of dispatch. This opens the question if we could have a `WorkerParentRunnable` base class that accounts for the differences between runnables meant to run on the worker and not, ensuring that we expect its `WorkerPrivate` to be alive only during `Dispatch` but not during `Run`, freezing all needed information during the dispatch.