Data Transfer Solutions

[00:00:00]
>> Kyle Simpson: For a while, this was okay, and then people started saying, well, web workers aren't useful, because not only is that inefficient from a memory perspective, but that also is very inefficient from a processing perspective. The whole point of the web worker is to be off thread and better, and if I have to make a copy of my 100 megabytes of data, that's no good.

[00:00:20]
So they had for a while, a thing called transferables, which was a way of basically creating a special kind of, like a ray data structure that you put some data into it and as soon as you posted it to a web worker, it went away from the web page.

[00:00:37]
They literally deleted it from the web page. And put it without copying, into the worker thread. And then vice versa, as soon as you posted it from a worker thread back to a page, it went away from the worker and put it back. So there's only ever one copy of that thing in any given place, but it's never in both places at once.

[00:00:58]
That seemed like an interesting and cool idea, as far as I'm aware, I mean, they shipped that, but that's been kinda deprecated. It seems like they went away from transferables, so that doesn't seem like something that's got much of a future. About two years ago or so, they shipped a feature called shared array buffers.

[00:01:19]
And by they, I mean the web platform java script. They shipped a feature called shared array buffers. And it was basically like the V2 of transferables. So it was a literal shared memory segment that could be accessed at the same time from two different threads of java script, which is a recipe for chaos.

[00:01:42]
But they also shipped another API on top of it, called atomics, which would allow you to do new Texas or semi fours or some other kind of blocking remotely so that only one of the threads was accessing the data, memory, the shared memory data at that point, but that was the idea was okay, we're just gonna stuff stuff in a shared memory segment.

[00:02:02]
Ship it off to a worker and then let it work on it and then let it tell us when it's done. So we'll just pull it back out of the same shared array memory. That sounds all well and good until about a year and a half ago. You might remember the CPU craziness that happened with the chips, I think it was called Specter or something like that, that came out and it was like being able to read people's private information out of memory or out of the process of RAM or something.

[00:02:34]
I forget all the technical details but it was essentially something like a vulnerability in the way processors worked and they were able to read this memory. Well it turns out That that was in part being exploited on web pages. Because the way that bug was exploited requires what's called a high resolution timer, meaning a timer that has down to the like nanosecond precision.

[00:02:57]
That's how those attack vectors generally work. And so we are actually always very careful about don't ship anything in the web platform that can give a high resolution timer, because then people are gonna exploit it. Well, it turns out shared array memory, shared array buffers are a perfect way of implementing high precision timing.

[00:03:18]
And that's exactly what they did, is they exploited that feature. So, very quickly, back like a year and a half, or whatever, very quickly, not even six months after that feature shipped, they shut those off. So we don't have shared array buffers. I think maybe one browser re-shipped it with the fix in place to prevent timers, or whatever.

[00:03:36]
But as far as I know at the moment, that's still kind of an influx problem. Every time they give us something cool, some jerk goes and abuses it and that's why we can't have nice things. So, the point is right now what you can rely upon cross browser is that you can send stuff copying strings and things, so do be aware of that if you're going to send a bunch of data.