Как идентифицировать задачи web worker через postMessage?

Question

[Сергей Соколов]

Общение со сторонним API выношу в web worker, чтобы не тормозил интерфейс. Запросы к API ограничены по частоте.

Инициируются запросы из разных мест в коде и надо как-то понимать, кому из ожидающих Promise'ов поступил очередной ответ.

Думаю, генерировать для каждой асинхронной «задачи» уникальный/случайный хэш. Передавать его в Worker вместе с данными для запроса, и при получении сообщения от Worker'а, каждый смотрит, не его ли хэш пришел с ответом.

new Promise((resolve, reject) => {
  const hash = Math.random();
  Worker.postMessage({
    hash: hash,
    otherData: 'other data'
  });
  Worker.addEventListener('message', m => {
    if(m.data.hash != hash) return;
    // наш ответ подоспел! Пляшем.
  });
})

Насколько это правильный подход и есть ли другие варианты решения задачи?

Answer 1

[Владимир Проскурин]

Вообще, встроенного механизма для такой задачи нет, т.к. все, что у нас есть, это postMessage, который умеет передавать только примитивы и Transferable объекты. Я вижу 2 варианта
1) Который вы предложили. Передавать хеш и потом при получении сообщения сравнивать. Только лучше делать не через замыкание (как у вас), а создать массив слушателей. Но это уже вылетает способ 2:
2) Сделать глобальную шину событий. Чтобы подписчики могли подписываться следующим образом

eventBase.on('worker.getLogin', function() { });
eventBase.on('worker.getEmail', function() { });

а в onmessage воркера просто запускать это событие

Worker.addEventListener('message', m => {
    eventBase.emit(`worker.${m.eventName}`);
});

Comments

[Сергей Соколов]

каждое обращение к worker уникальное, поэтому нет названий событий типа worker.getLogin. Один вызов, один ответ, один получатель, один раз.
В чем недостаток варианта с замыканиями?

[Сергей Соколов]

Понял, что вместо читабельных названий worker.getLogin у меня могут быть те же хэши.. Но в чем смысл доп прослойки в виде шины событий? Чем лучше, чем слушать прямо на worker'е?

[Владимир Проскурин]

Сергей Соколов,

В чем недостаток варианта с замыканиями?

ИМХО, для каждого получается будет производится вызов события и передача значения в него. Мне неизвестно, сколько слушателей будет, и как плохо это скажется на производительности (в принципе надо бенчмарки запускать). Если уверены, что слушателей не много, то можно.
Еще вот такая штука есть https://github.com/nolanlawson/promise-worker там автор делает массив слушателей и один onmessage.

[Владимир Проскурин]

Сергей Соколов, на 10000 слушателей заметен эффект, массив обработчиков почти в 2 раза быстрее

var response = "self.onmessage=function(e){postMessage('Worker: '+e.data);}";
var count = 10000;
var blob;
try {
    blob = new Blob([response], {type: 'application/javascript'});
} catch (e) { // Backwards-compatibility
    window.BlobBuilder = window.BlobBuilder || window.WebKitBlobBuilder || window.MozBlobBuilder;
    blob = new BlobBuilder();
    blob.append(response);
    blob = blob.getBlob();
}
var worker1 = new Worker(URL.createObjectURL(blob));
var worker2 = new Worker(URL.createObjectURL(blob));

for(var i = 0; i < count; i++) {
   let a = 0;
   worker1.addEventListener('message', function (e) { a = e; });
}

var listeners = [];
for(var i = 0; i < count; i++ ) {
   let a = 0;
   listeners.push(function (e) { a = e; });
}
worker2.addEventListener('message', function (e) {
	for(var i = 0; i < count; i++) {
       listeners[i](e);
    }
});

console.time('worker1');
worker1.postMessage('Test');
console.timeEnd('worker1');

console.time('worker2');
worker2.postMessage('Test');
console.timeEnd('worker2');

// worker1: 0.031005859375ms
// worker2: 0.017822265625ms

[Сергей Соколов]

Владимир Проскурин, в моей задаче запросов на порядки меньше: десятки, до сотен не дойдёт. Но тяжелый payload и в запросе, и в ответе.
Спасибо за ссылку на promise-worker! Посмотрел, как сделано – даже лучше чем hash – так как единая точка входа, просто инкрементируется счётчик.