Forever loop while waiting for asynchronous task?

Question

I'm wondering if there's a way to cause JavaScript to wait for some variable-length code execution to finish before continuing using events and loops. Before answering with using timeouts, callbacks or referencing this as a duplicate, hear me out.

I want to expose a large API to a web worker. I want this API to feel 'native' in the sense that you can access each member using a getter which gets the information from the other thread. My initial idea was to compile the API and rebuild the entire object on the worker. While this works (and was a really fun project), it's slow at startup and cannot show changes made to the API without it being sent to the worker again after modification. Observers would solve part of this, and web workers transferrable objects would solve all, but they aren't adopted widely yet.

Since worker round-trip calls happen in a matter of milliseconds, I think stalling the thread for a few milliseconds may be an alright solution. Of course I would think about terminating in cases where calls take too long, but I'm trying to create a proof of concept first.

Let's say I want to expose the api object to the worker. I would define a getter for self.api which would fetch the first layer of properties. Each property would then be another getter and the process would continue until the final object is found.

worker.js

self.addEventListener('message', function(event) {
    self.dataRecieved = true;
    self.data = event.data; // would actually build new getters here
});

Object.defineProperty(self, 'api', {
    get: function() {
        self.dataRecieved = false;
        self.postMessage('request api first-layer properties');
        while(!self.dataRecieved);
        return self.data; // whatever properties were received from host
    }
});

For experimentation, we'll do a simple round-trip with no data processing:

index.html (only JS part)

var worker = new Worker("worker.js");
worker.onmessage = function() {
    worker.postMessage();
};

If onmessage would interrupt the loop, the script should theoretically work. Then the worker could access objects like window.document.body.style on the fly.

My question really boils down to: is there a way to guarantee that an event will interrupt an executing code block?

From my understanding of events in JavaScript, I thought they did interrupt the current thread. Does it not because it's executing a blank statement over and over? What if I generated code to be executed and kept doing that until the data returned?

I'm not going to post this as an answer because it's not what you want to hear. Events don't interrupt the current thread. Instead the thread runs all javascript code until there is nothing else to run (reach the end of all code) then the eventloop runs processing events. So its' execute->process_events->execute->process_events... forever. There's no interrupt — slebetman, Apr 07 '15 at 07:23
If you keep executing code until data returns then the data will never return (never here means up till the heat-death of the universe or the destruction of your computer or when you kill the process, whichever comes first). This is because you never allow the eventloop to run thus events will never happen — slebetman, Apr 07 '15 at 07:29

score 1 · Accepted Answer · edited May 23 '17 at 10:24

is there a way to guarantee that an event will interrupt an executing code block

As @slebetman suggests in comments, no, not in Javascript running in a browser's web-worker (with one possible exception that I can think of, see suggestion 3. below).

My suggestions, in decreasing order of preference:

Give up the desire to feel "native" (or maybe "local" might be a better term). Something like the infinite while loop that you suggest also seems to be very much fighting agains the cooperative multitasking environment offered by Javascript, including when thinking about a single web worker.

Communication between workers in Javascript is asynchronous. Perhaps it can fail, take longer than just a few milliseconds. I'm not sure what your use case is, but my feeling is that when the project grows, you might want to use those milliseconds for something else.

You could change your defined property to return a promise, and then the caller would do a .then on the response to retrieve the value, just like any other asynchronous API.
Angular Protractor/Webdriver has an API that uses a control flow to simulate a synchronous environment using promises, by always passing promises about. Taking the code from https://stackoverflow.com/a/22697369/1319998
```
browser.get(url);
var title = browser.getTitle();
expect(title).toEqual('My Title');
```
By my understanding, each line above adds a promise to the control flow to execute asynchronously. title isn't actually the title, but a promise that resolves to the title for example. While it looks like synchronous code, the getting and testing all happens asynchronously later.

You could implement something similar in the web worker. However, I do wonder whether it will be worth the effort. There would be a lot of code to do this, and I can't help feeling that the main consequence would be that it would end up harder to write code using this, and not easier, as there would be a lot of hidden behaviour.
The only thing that I know of that can be made synchronous in Javascript, is XMLHttpRequest when setting the async parameter to false https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest#Parameters. I wonder if you could come up with some sort of way to request to the server that maintains a connection with the main thread and pass data along that way. I have to say, my instinct is that this is quite an awful idea, and would be much slower than just requesting data from the main thread.

score 0 · Answer 2 · answered Apr 07 '15 at 07:22

For what I know, there is not something native in JS to do this but it is relatively easy to do something similar. I made one some time ago for myself: https://github.com/xpy/whener/blob/master/whener.js .

You use it like when( condition, callback ) where condition is a function that should return true when your condition is met, and callback is the function that you want to execute at that time.

Forever loop while waiting for asynchronous task?

2 Answers2