3 ms·

> and then use Atomics.wait on the main thread to block The main thread is not allowed to use Atomics.wait. I’m not certain what the implementation status of t

> and then use Atomics.wait on the main thread to block The main thread is not allowed to use Atomics.wait. I’m not certain what the implementation status of this is because I’ve never used it and I have a vague feeling I heard that one browser shipped it without that restriction, but at the very least you may get a TypeError in some user agents and you can expect to in all user agents at some point in the future when they become sterner about not blocking the main thread. As for stopping synchronous operations, I’m dubious that would actually work; without actually testing it (and I don’t have time to test it now, though I’d be interested in the result, including across various platforms), I think it’s more likely that the regexp match would be uninterruptable, and that it would just go on munching your CPU until it finished, and then terminate once it returned from the native code to the JavaScript.

fabiospampinato 5y ago
I should check what's the status with Atomics.wait on Chrome, currently it seems to work fine under both Node and Deno. I'll test out the regex thing in the following days as I need it for that exact use case, I just assumed killing the web worker would... work, hopefully that's the case otherwise I'm back to square 0 :D --- Edit: MDN says: "The terminate() method of the Worker interface immediately terminates the Worker. This does not offer the worker an opportunity to finish its operations; it is stopped at once." so if that's not the case either the engine is wrong or the docs are wrong.
- chrismorgan 5y ago
  Worker.terminate() aborts the currently running script evaluation, see https://html.spec.whatwg.org/multipage/workers.html#dom-worker-terminate-dev https://html.spec.whatwg.org/multipage/workers.html#dom-work... → https://html.spec.whatwg.org/multipage/workers.html#terminate-a-worker https://html.spec.whatwg.org/multipage/workers.html#terminat... → https://html.spec.whatwg.org/multipage/webappapis.html#abort-a-running-script https://html.spec.whatwg.org/multipage/webappapis.html#abort..., but that’s a fairly fuzzy definition, and it’s not generally reasonable to expect that to interrupt a currently executing piece of native code, because interrupting that (e.g. by sending a signal to the thread and forcibly starting unwinding) could leave data structures in a memory-unsafe state (that is, in the improbable worst case this could be a vector for escaping the sandbox). It’s possible they’ve come up with some way of working around this, but it’s going to be considerably easier and safer to just treat native code as uninterruptible by default, and possibly get known-slow blocking operations to manually periodically check if they’re being asked to stop. So I say my gut feeling is that the match operation won’t actually be interrupted, and I wouldn’t be inclined to depend on it actually being interrupted without explicit documentation of what aborting does, even if all environments I cared about did abort it immediately.
  - fabiospampinato 5y ago
    At least in Chrome it works as advertised: https://twitter.com/fabiospampinato/status/1468309310480474124 https://twitter.com/fabiospampinato/status/14683093104804741...
    - chrismorgan 5y ago
      Syntax errors there, t.co mangulation of e.data. Seems to work in Chromium, though it looks like it might be taking a second or two to actually terminate it. It’s a bit harder to tell if it works in Firefox, because Firefox kills the regular expression within five seconds with the error from RegExpBuiltinExec “too much recursion”, but I think it is, and probably faster than Chromium, though it’s hard to be certain when just doing the lazy check of CPU usage at one second granularity.
      - fabiospampinato 5y ago
        > Syntax errors there, t.co mangulation of e.data. Interesting! They must have changed something because when I published that the code looked alright, albeit with some stuff linkified.

fabiospampinato 5y ago

I should check what's the status with Atomics.wait on Chrome, currently it seems to work fine under both Node and Deno. I'll test out the regex thing in the following days as I need it for that exact use case, I just assumed killing the web worker would... work, hopefully that's the case otherwise I'm back to square 0 :D --- Edit: MDN says: "The terminate() method of the Worker interface immediately terminates the Worker. This does not offer the worker an opportunity to finish its operations; it is stopped at once." so if that's not the case either the engine is wrong or the docs are wrong.

chrismorgan 5y ago
Worker.terminate() aborts the currently running script evaluation, see https://html.spec.whatwg.org/multipage/workers.html#dom-worker-terminate-dev https://html.spec.whatwg.org/multipage/workers.html#dom-work... → https://html.spec.whatwg.org/multipage/workers.html#terminate-a-worker https://html.spec.whatwg.org/multipage/workers.html#terminat... → https://html.spec.whatwg.org/multipage/webappapis.html#abort-a-running-script https://html.spec.whatwg.org/multipage/webappapis.html#abort..., but that’s a fairly fuzzy definition, and it’s not generally reasonable to expect that to interrupt a currently executing piece of native code, because interrupting that (e.g. by sending a signal to the thread and forcibly starting unwinding) could leave data structures in a memory-unsafe state (that is, in the improbable worst case this could be a vector for escaping the sandbox). It’s possible they’ve come up with some way of working around this, but it’s going to be considerably easier and safer to just treat native code as uninterruptible by default, and possibly get known-slow blocking operations to manually periodically check if they’re being asked to stop. So I say my gut feeling is that the match operation won’t actually be interrupted, and I wouldn’t be inclined to depend on it actually being interrupted without explicit documentation of what aborting does, even if all environments I cared about did abort it immediately.
- fabiospampinato 5y ago
  At least in Chrome it works as advertised: https://twitter.com/fabiospampinato/status/1468309310480474124 https://twitter.com/fabiospampinato/status/14683093104804741...
  - chrismorgan 5y ago
    Syntax errors there, t.co mangulation of e.data. Seems to work in Chromium, though it looks like it might be taking a second or two to actually terminate it. It’s a bit harder to tell if it works in Firefox, because Firefox kills the regular expression within five seconds with the error from RegExpBuiltinExec “too much recursion”, but I think it is, and probably faster than Chromium, though it’s hard to be certain when just doing the lazy check of CPU usage at one second granularity.
    - fabiospampinato 5y ago
      > Syntax errors there, t.co mangulation of e.data. Interesting! They must have changed something because when I published that the code looked alright, albeit with some stuff linkified.