Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't expose lc0 worker to an asynchronous function #19

Open
patrickfrank1 opened this issue Feb 18, 2019 · 1 comment
Open

Can't expose lc0 worker to an asynchronous function #19

patrickfrank1 opened this issue Feb 18, 2019 · 1 comment

Comments

@patrickfrank1
Copy link

patrickfrank1 commented Feb 18, 2019

Hi there,
I'm trying to use lc0_js asynchronously, one idea to do so would be a constunct like the following:

class Lc0 {
  constructor(){
    //the functions from your library
    CreateLC0Worker()
     .then(this.initEngine.bind(this))
     .catch(this.showError.bind(this));
  }
  
  initEngine(worker) {
    this.worker = worker;
    this.worker.onmessage = null;
    this.worker.onerror = this.engineError.bind(this);
    this.worker.postMessage('load ' + this.weightsUrl);
  }

  computeMove() {
    this.worker.onmessage = e => {
      return new Promise((resolve,reject) => {
        /* ... */
        if (Array.isArray(message)) {...}
        else {
          var match = message.split(" ");
          if (match.includes("bestmove")) {
            alert("bestmove found");
            resolve();
          }
        }
      });
    };
  }

  async goDepth(d){
    let s = this.computeMove();
    this.send(`go depth ${d}`);
    await s;
    alert("Promise resolved");
  }
}

Remark that it works just fine for engines like stockfish.
There are other ways to make this asynchronous, but the idea is always to resolve a promise on "bestmove".
Probably it has to do with your implementation of the worker (also it is less than optimal that the console is blocked...).

Do you have an idea where the problem could originate from? Or do you have a better idea on how to expose the worker to an asynchronous function?

Best regards,
Patrick

P.S.: Thanks for putting this awesome project out there, I like it a lot 💯

@frpays
Copy link
Owner

frpays commented Mar 18, 2019

Hey,

Thanks for bringing up this issue, and sorry with the delay. Maybe you moved on, but that's an interesting issue to comment on, so I will gladly do anyway.

There are two distinct code paths.

let useWebWorker = 'undefined' != typeof OffscreenCanvas;

If we detect a usable javascript Worker with a working Offscreen canvas implementation, then we create a Worker where lc0 will run asynchronously with respect to the user interface. The javascript Worker will have its own dedicated thread, and the main javascript thread hosting the user interface will communicate with the worker using non blocking postmessage(), receiving the bestmove with onmessage(). As a result, the user interface is reasonably smooth.

If we cannot detect a Worker, then we create a LC0Worker class instance that mimics the Worker interface (postmessage() and onmessage() looks the same). As a result the rest of the code is pretty much identical. But the crucial difference is the engine is no longer asynchronous. In the use case of go/bestmove, postmessage() does not returns before the onmessage() is called. As a result, the user interface is frozen when the engine computes the best move. These are 'degraded mode' conditions.

The Worker is the recommended way to interact with lc0 asynchronously. It will work out-of-the-box on Chrome. You will have to enable the offscreen canvas on Firefox. Sadly, on some browsers, it won't work at all.

How can you make lc0 works asynchronously without javascript Worker and Offscreen canvas?

I am afraid you cannot. The async keyword is syntactic sugar for premises and won't create any particular thread context. The lc0 engine is compiled with Emscripten without thread support, so the user interface and lc0 share the same thread. When you call Step() on the engine, the user interface has to be frozen.

Note that the user-interface is really frozen during the call to Step() which in return call RunOneIteration() on the engine. The user-interface actually "breathes" between calls and process messages (mouse move or press), but the results nonetheless looks "jerky".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants