3 ms·

Funny I almost commented that you must be mistaken because it would be positively insane to support synchronous requests. Wow, that is insane. In the end, sync

by lolc 6y ago

Funny I almost commented that you must be mistaken because it would be positively insane to support synchronous requests. Wow, that is insane. In the end, synchronization can be achieved by busy waiting. So the implementation of apiService.sql() could just rely on that even if the browser API didn't support it. The code still looks fake to me. Because you have to know quite a bit to create a combination of fails like that. Natural bad code I've seen is less purposefully structured. But maybe I just haven't been exposed to this type.

Izkata 6y ago
> In the end, synchronization can be achieved by busy waiting. So the implementation of apiService.sql() could just rely on that even if the browser API didn't support it. I haven't tested this, but I don't think it can. The result callback doesn't have a chance to run if there's a busy loop - javascript is single-threaded, and callbacks only fire when idle (think cooperative multitasking, not preemptive multitasking). Webworkers may get around this, but I've not used them and am not sure of the details on how they work. A quick look at a guide indicates they still rely on event callbacks in the main thread, so if my thought above is right, it looks like they wouldn't work either.
- lolc 6y ago
  It's true! I tested it because I thought it would be possible to just wait for readyState == 4 in a loop. My assumption was that XMLHttpRequest runs in another thread once you do send() on it. And indeed, the request starts immediately. But the instance of XMLHttpRequest doesn't get updated until control is yielded. So you can't get the goods. All considered, that is a good thing :-)
CodesInChaos 6y ago
A couple of years ago slack used synchronous requests to fetch the history when scrolling up on the main chat window. Page/browse freezing included. I think it even used a full CPU core spinning instead of blocking on IO.

by lolc 6y ago

Izkata 6y ago

> In the end, synchronization can be achieved by busy waiting. So the implementation of apiService.sql() could just rely on that even if the browser API didn't support it. I haven't tested this, but I don't think it can. The result callback doesn't have a chance to run if there's a busy loop - javascript is single-threaded, and callbacks only fire when idle (think cooperative multitasking, not preemptive multitasking). Webworkers may get around this, but I've not used them and am not sure of the details on how they work. A quick look at a guide indicates they still rely on event callbacks in the main thread, so if my thought above is right, it looks like they wouldn't work either.

lolc 6y ago
It's true! I tested it because I thought it would be possible to just wait for readyState == 4 in a loop. My assumption was that XMLHttpRequest runs in another thread once you do send() on it. And indeed, the request starts immediately. But the instance of XMLHttpRequest doesn't get updated until control is yielded. So you can't get the goods. All considered, that is a good thing :-)

CodesInChaos 6y ago

A couple of years ago slack used synchronous requests to fetch the history when scrolling up on the main chat window. Page/browse freezing included. I think it even used a full CPU core spinning instead of blocking on IO.