Выполняет ли loopback 4.0 запросы параллельно? - PullRequest
0 голосов
/ 21 апреля 2020

Я пытаюсь понять контексты в Loopback 4 .

Одна вещь, которая не имеет смысла для меня, это то, как Loopback может сказать, каким должен быть контекст, если когда-либо был два асинхронных запроса, выполняющихся параллельно.

Как в:

const ctx;

for (let i = 0; i < 10; i++) {
  ctx.set("i", i);
  endpointCall();
}

async function endpointCall() {
  return new Promise((resolve) => {
    setTimeout(
      () => { resolve `The context variable i equals ${ctx.get(i)}`,
      Math.random() * 500,
    )

  });
}

Очевидно, что вышеописанное не будет работать. На самом деле, я не могу представить, что Loopback сможет определить контекст, в котором ожидаются две или более конечных точки одновременно.

Так что loopback 4.0 выполняет запросы параллельно когда-нибудь?


Внимание: JS однопоточный, но двигатели, которые работают JS, как правило, нет. Например, движок может читать несколько потоков одновременно. Он по-прежнему будет передавать данные только в среду JS синхронно.


Ясность: что из следующего больше похоже на обратную петлю

Ожидание обратной связи для последнего API вызовите fini sh перед запуском следующего, или он когда-либо запускает их асин c -параллельно?

1 Ответ

0 голосов
/ 21 апреля 2020

Нет, не . Но это характеристика c из JavaScript.


Фрагмент кода кажется неполным. Поэтому для ясности предположим, что используется следующий код:

const Context = require('@loopback/context').Context;

const ctx = new Context();

async function main() {
  for (let i = 0; i < 10; i++) {
    ctx.bind('i').to(i);

    new Promise(() => {
      setTimeout(
        async () => {
          console.log(`The context variable i equals ${await ctx.get('i')}`);
        },
        Math.random() * 500,
      )
    });
  }
}

main()

. Он достигает тех же целей, что и исходный фрагмент кода:

  • L oop 10 раз
  • Перепривязать значение 'i' с шагом 1
  • Вызов ctx.get() после "случайной" продолжительности
  • Помещает setTimeout в свое обещание

Мы используем @loopback/context напрямую, так как функции-оболочки @loopback/rest вызывают их внутренне.

Мы также не resolve -ing, поскольку в этом примере нет практической разницы (мы не await -ing или не использует ответ).


как Loopback может определить контекст, если когда-либо параллельно выполнялись два асинхронных запроса

Хотя ctx.get() и ctx.bind() являются асинхронными функциями, JavaScript по-прежнему однопоточен. Это означает, что эти функции будут поставлены в очередь в событии l oop и, следовательно, будут записывать или читать состояние в порядке поступления заявок.

Однако a for-l oop заблокирует событие l oop. Это означает, что вращение другого Обещания без await -ing для его разрешения приведет к тому, что Обещание будет задержано с помощью for-l oop.

Асинхронность не совпадает с многопоточностью. Это означает, что всегда будет очередь, и «условия гонки» не будут такими же, как у многопоточных языков программирования.

The context variable i equals 9
The context variable i equals 9
The context variable i equals 9
The context variable i equals 9
The context variable i equals 9
The context variable i equals 9
The context variable i equals 9
The context variable i equals 9
The context variable i equals 9
The context variable i equals 9
The context variable i equals 9
The context variable i equals 9
The context variable i equals 9
The context variable i equals 9
The context variable i equals 9
The context variable i equals 9
The context variable i equals 9
The context variable i equals 9
The context variable i equals 9
The context variable i equals 9

Результаты совпадают с ctx.getSync().


Следовательно, LoopBack Context не обрабатывает запросы параллельно, поскольку JavaScript является однопоточным.

Дополнительная информация:

...