Что такое модель Meteor concurrency?

Я пишу серверную логику для приложения Meteor, которое должно обновлять состояние в памяти в ответ на запросы клиента. Это приложение нуждается в надежных гарантиях concurrency - в частности, я хочу быть уверенным, что за один раз выполняется только одно обновление.

Я пытаюсь выяснить, поддерживает ли модель Meteor concurrency. В документации упоминается, что Meteor многопоточен (что будет проблемой), но после поиска у меня создается впечатление, что Meteor фактически использует волокна (явно запланированные потоки). Если это правда, тогда я в безопасности, пока часть моего кода, который должен запускаться атомарно, не выполняет никаких вызовов Meteor (которые включают IO и, следовательно, обеспечивают блокировку выполнения).

Это так? Где я могу найти дополнительную информацию о модели Meteor concurrency?

Ответ 1

Хорошо, я просмотрел источник Метеор и здесь, как все работает:

1) На стороне сервера Meteor использует только волокна для обработки concurrency. Волокна похожи на потоки, за исключением того, что контекст должен быть явно предоставлен. Это облегчает рассуждение о concurrency при (потенциальной) стоимости некоторых волокон, голодающих другими.

2) Все вызовы Meteor.call, Meteor.setInterval и любые операции коллекции завертываются в волокна. Это означает, что все эти вызовы дают контекст.

3) Кроме того, любое использование модуля волокон/фьючерсов дает.

Результатом этой структуры является то, что если вы хотите написать атомные операции, просто избегайте доступа к объектам, предоставленным средой Meteor, в блоке кода, который вы хотите сделать атомарным. Если этот блок действительно нуждается (скажем) в доступе к БД, то вы можете беспрепятственно реализовать блокировки в памяти, но для моего приложения этого знания достаточно. Моя основная функция обновления просто должна быть вызвана со всеми документами, которые ей нужны из Mongo, которые уже были прочитаны.

Ответ 2

Из метеорных документов:

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

http://docs.meteor.com/#structuringyourapp

Кто-нибудь знает последствия этого для производительности?