4 ms·

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 fo

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.

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.