Насколько я в курсе, вызовы API сериализуются в пределах коннекта на уровне Y-valve. А что
если исключить из картины Y-valve и работать непосредственно с плагином движка? Насколько
в этом случае можно распараллелиться без особой опасности для жизни и здоровья?

Два запроса в одной транзакции точно устроят гонки за объектами транзакции (сейфпоинтами и
т.п.), а как насчёт разных транзакций в разных потоках?
Posted via ActualForum NNTP Server 1.5

Симонов Дениса что ты такое пытаешься сделать?

В качестве гимнастики для ума я пытаюсь выдумать асинхронное API и/или сетевой протокол.

Сейчас оно работает с полным квитированием, то бишь, например: старт транзакции-ожидание
подтверждения от сервера-препарирование
запроса-ожидание-выполнение-ожидание-фетч-ожидание. Если исключить хотя бы половину этих
ожиданий, то есть старт-препарирование-ожидание-выполнение-фетч-ожидание, то на сетях с
высокой латентностью можно было бы ускориться раза в два. Часть ожиданий уже убрали в
двойке, но их ещё осталось достаточно.

И вот тут встаёт вопрос очерёдности обработки пакетов. Две простейшие идеи приходящие в
голову:
1) Одна очередь, Х потоков выбирают задания и выполняют их.
2) Х очередей по одной на поток и используемая очередь фиксируется на коннект/транзакцию.

В первом случае проблема очевидна: препарирование может обогнать старт транзакции и
обломиться.
Во-втором случае есть риск, что два тяжёлых коннекта встанут в одну очередь пока остальные
будут бездельничать. Если бы было возможно привязывать к потоку не коннект, а хотя бы
транзакцию - риск уменьшается.
Posted via ActualForum NNTP Server 1.5

Гаджимурадов РустамПочему бы не спросить это в девеле?

Во-первых, с некоторых пор меня напрягает английский.
Во-вторых, там те же самые два с половиной человека с тем же самым желанием.
Posted via ActualForum NNTP Server 1.5