TFFI

Да, на слайдах ( https://www.slideshare.net/esug/nonblocking-strategies-for-ffi , страница 10, у меня доступно только через VPN) рассматривается Стратегия 1 (Thread per callout). Во-первых, "рассматривается" и "реализовано" не одно и то же. Во вторых, в СУБД-ных (DB2 и Oracle как минимум) все вызовы одного коннекта должны быть в одной нити.

То бишь, если Smalltalk-процесс сделал вызов СУБД-шной библиотеки в нити T, следущий вызов тоже должен быть в нити T. Для небольшого (несколько сотен; то бишь не Twitter с Facebook, а что-то вроде корпоративного) приложения можно было бы просто ассоциировать ST-процесс и внешнюю нить.

On Monday, August 31, 2020 at 11:46:11 AM UTC+5 vvm13xyz xyz wrote:

Случайно обнаружил https://github.com/pharo-project/threadedFFI-Plugin .

Сперва немного порадовался, потом стал читать https://github.com/pharo-project/threadedFFI-Plugin/wiki/Using-with-UFFI и был шокирован.

Или я чего-то не понимаю, или эта штука малополезна.

In the current state, TFFI supports three running strategies:

• TFSameThreadRunner: this strategy runs the callouts in the same system thread than the VM is running. This strategy implements the same behavior that SqueakFFI has. Performing calls with this strategy blocks the execution of the VM until the callout is ended.

• TFWorker: This strategy runs the callouts using a separate thread of the VM, allowing the VM to continue executing other Smalltalk processes. This strategy can use a common thread or a different thread per library.

• TFMainThreadRunner: this strategy runs the callouts in the main thread of the application. This runner is only working when the VM is launched in a thread different than the main one (for example, to use alternative UI libraries).

Первая бесполезна вообще, третью я не очень понимаю, но по виду тоже бесполезна. Есть смысл говорить о второй, которая кажется чуть более перспективной, но лишь чуть.

Положим, есть Seaside-приложение. Без TFFI, если оно вызовет что-то долгоиграющее, зависнут все клиенты. Стратегия TFWorker, если работает только per library, приведёт примерно к тому же. Обращение к СУБД второго юзера станет в очередь и будет там находиться, пока обращение первого юзера не выполнится. Да, те процессы, которые не обращаются к базе, будут работать. Но поскольку каждое обращение к веб-странице порождает запрос к базе, все юзеры будут висеть.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/sugr/28244ef2-f8ed-40ca-bad0-37d2526000b0n%40googlegroups.com.

Случайно обнаружил https://github.com/pharo-project/threadedFFI-Plugin .

Сперва немного порадовался, потом стал читать https://github.com/pharo-project/threadedFFI-Plugin/wiki/Using-with-UFFI и был шокирован.

Или я чего-то не понимаю, или эта штука малополезна.

In the current state, TFFI supports three running strategies:

• TFSameThreadRunner: this strategy runs the callouts in the same system thread than the VM is running. This strategy implements the same behavior that SqueakFFI has. Performing calls with this strategy blocks the execution of the VM until the callout is ended.

• TFWorker: This strategy runs the callouts using a separate thread of the VM, allowing the VM to continue executing other Smalltalk processes. This strategy can use a common thread or a different thread per library.

• TFMainThreadRunner: this strategy runs the callouts in the main thread of the application. This runner is only working when the VM is launched in a thread different than the main one (for example, to use alternative UI libraries).

Первая бесполезна вообще,

третью я не очень понимаю, но по виду тоже бесполезна.

Есть смысл говорить о второй, которая кажется чуть более перспективной, но лишь чуть.

Положим, есть Seaside-приложение. Без TFFI, если оно вызовет что-то долгоиграющее, зависнут все клиенты. Стратегия TFWorker, если работает только per library, приведёт примерно к тому же. Обращение к СУБД второго юзера станет в очередь и будет там находиться, пока обращение первого юзера не выполнится. Да, те процессы, которые не обращаются к базе, будут работать. Но поскольку каждое обращение к веб-странице порождает запрос к базе, все юзеры будут висеть.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/sugr/49cd579f-268a-43e0-af2a-95ce1feab760n%40googlegroups.com.