| 17:05 | <ljharb> | https://es.discourse.group/t/atomics-wait-waitasync-as-native-settimeout/1120 seems interesting; cc erights - would it maybe be possible to specify setTimeout in the language? |
| 17:06 | <Jack Works> | https://es.discourse.group/t/atomics-wait-waitasync-as-native-settimeout/1120 seems interesting; cc erights - would it maybe be possible to specify setTimeout in the language? |
| 17:08 | <Jack Works> | This post is interesting but it requires SAB and worker (?) so it isn't so useful |
| 17:19 | <ljharb> | It doesn’t appear to require a worker |
| 17:20 | <ljharb> | it was rejected for a number of reasons, but one was that there’s no concept of time like this in the spec - but if Atomics.waitAsync already provided it - iow, if setTimeout can be polyfilled without using new Date/Date.now, and with only things in 262 - I’m not sure what the remaining reasons would be to reject it. |
| 17:22 | <Jack Works> | So his polyfill dont need current thread to be blockable? |
| 17:22 | <Jack Works> | And is Atomics normative optional? |
| 17:24 | <bakkot> | waitAysnc works on the main thread, yeah; that's the point of it |
| 17:24 | <bakkot> | and no, atomics is not normative optional |
| 17:26 | <Jack Works> | Hmm. SAB is normative optional and Atomics only works with SAB, is that true? |
| 17:30 | <bakkot> | SAB is not exactly normative optional, though it's complicated |
| 17:31 | <bakkot> | the "SharedArrayBuffer" property of the global object is normative optional in hosts which do not provide multithreading, and that's the only built-in way to get access to a SAB in ES, but other hosts provide other mechanisms to get at it |
| 17:32 | <bakkot> | also the only reason we made that change was web-compat when everyone turned off SABs for a while because of spectre |
| 17:34 | <Jack Works> | Is there any case that SAB is not exposed on global but will be returned by a host API? |
| 17:35 | <bakkot> | yes, let me dig it up |
| 17:36 | <bakkot> | new WebAssembly.Memory({ shared:true, initial:0, maximum:0 }).buffer.constructor |
| 17:36 | <Jack Works> | And it can be called to create new SAB? |
| 17:36 | <bakkot> | works even when multithreading is disabled |
| 17:36 | <bakkot> | yes |
| 17:36 | <Jack Works> | It's crazy |
| 17:37 | <Jack Works> | Then what's the meaning of hiding it... |
| 17:37 | <bakkot> | web compat |
| 17:37 | <bakkot> | like I said |
| 17:38 | <bakkot> | a lot of code assumes that if the SAB constructor was present then they could do multithreading, and had a fallback for when it was not available |
| 17:38 | <bakkot> | so when browsers turned of multithreading, for spectre, they needed to also remove the SAB property of the global |
| 17:38 | <bakkot> | note that just getting an SAB doesn't give you the ability to do multithreading |
| 17:38 | <Jack Works> | I mean, if they want to hide SAB, why not hide it completely but leave an escape path in WebAssembly |
| 17:39 | <bakkot> | they don't want to hide SAB |
| 17:39 | <bakkot> | that was not the goal |
| 17:40 | <bakkot> | the goal was, "remove multithreading, and do not break websites which assume that the existence of the SAB property on the global implies the ability to do multithreading" |
| 17:40 | <Jack Works> | Isn't Shared WebAssembly memory is used for multithreading? |
| 17:40 | <bakkot> | (sorry, and by "multithreading" I mean specifically "multhreaded access to shared memory", not just the ability to spawn workers) |
| 17:40 | <bakkot> | yes, but what browsers did is disabled the ability to pass a SAB between workers |
| 17:41 | <bakkot> | if you can't pass an SAB between workers, you don't have shared memory |
| 17:41 | <bakkot> | but the WASM api is spec'd to be backed by an SAB regardless of whether multithreading is enabled |
| 17:42 | <Jack Works> | Aren't WebAssembly also affected by spectre when necessary methods provided? |
| 17:44 | <bakkot> | if the necessary methods (i.e. the ability to use multithreaded access to shared memory to make a high-res timer) are provided, yes |
| 17:44 | <bakkot> | but I believe this ability is not provided in the relevant case |
| 17:45 | <bakkot> | you can read more of the discussion in https://github.com/whatwg/html/issues/4175, https://github.com/whatwg/html/issues/3740, https://github.com/tc39/ecma262/issues/1435, https://github.com/tc39/ecma262/pull/1903 |
| 17:45 | <Jack Works> | Okay I guess I understand what happened to SAB now... |
| 17:47 | <Jack Works> | So back to Atomics was added, how the committee decided about adding a clock API? Was there any security concerns raised? Is that possible to add things like Promise.timeout? |
| 17:48 | <bakkot> | honestly I think people may have just not noticed at the time waitAsync was being added |
| 17:48 | <bakkot> | unfortunately it's hard to get in touch with erights, short of making a proposal and bringing it to plenary |
| 17:48 | <bakkot> | I think it's worth a shot |
| 17:49 | <Jack Works> | 😰 |
| 17:50 | <bakkot> | oh, or just asking him during plenary, at the lunch break |
| 17:50 | <bakkot> | that's what I usually do |
| 18:00 | <devsnek> | I'm down for timers in the stdlib |
| 18:06 | <bakkot> | let delay = ms => new Promise(res => setTimeout(res, ms)) is one of those incantations I put at the top of many of my scripts; would be nice to not do that |
| 18:09 | <bakkot> | though looking around some, it seems like chrome (or at least Domenic) is of the opinion that it would need to be in HTML instead of ES and also that it would need to have AbortController integration: https://github.com/whatwg/html/issues/617#issuecomment-702774052 |
| 18:09 | <bakkot> | so I guess it's not gonna happen anyway |
| 18:09 | <bakkot> | sigh |
| 18:09 | <devsnek> | don't worry in 15 years half of html will be merged with 262 |
| 18:10 | <bakkot> | that is gonna depend highly on the specifics of the individuals working on these specs in the next decade, is my feeling |
| 18:11 | <bakkot> | though, abortcontroller is probably the thing most likely to end up in 262, I guess |
| 19:18 | <bterlson> | I like Ron's proposal around this personally. A protocol would be useful. |
| 19:20 | <bterlson> | cancelSignal and dispose would be so nice in my world |
| 19:59 | <rbuckton> | A protocol is the most flexible approach, but I've been getting push back against it in favor of a host hook instead. |