1806499 - Cleanup WASM signal handler initialization

Status: RESOLVED FIXED

(Core :: JavaScript: WebAssembly, task, P1)

Description

[Ted Campbell [:tcampbell]]

WASM signal handling on OSX uses a special handler thread which we'd like to lazily create. During various stencil work we accidentally started trigger this lazy initialization pretty eagerly from CompileOptions constructor.

To make this actually lazily on first WASM use, it probably makes more sense to check in link/instantiation code instead of parsing. Doing this also lets us remove these checks from CompileOptions and asm.js parsing.

Comment 1

[Ted Campbell [:tcampbell]]

Jan, this is not high priority but you are probably the best person to untangle this in the future.

Comment 2

[Jan de Mooij [:jandem]]

Attachment: Bug 1806499 - Move signal handler initialization out of HasPlatformSupport. r?rhunt!

After some of the Stencil changes, we now end up calling HasPlatformSupport from the
CompileOptions constructor when parsing any JS code (to check for asm.js availability).

This means we were installing the Wasm signal handlers for every process that executes
JS code. On Mac we need to create a separate thread for these signal handlers, so there is
some overhead that we want to avoid when we're not executing asm.js or Wasm code.

This patch moves the EnsureFullSignalHandlers call out of HasPlatformSupport.
We now call this when instantiating the asm.js or Wasm module.

This also simplifies the WASI build a little.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/66acd89da902
Move signal handler initialization out of HasPlatformSupport. r=rhunt

Comment 4

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/66acd89da902