TFFI

Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

TFFI

vvm13xyz xyz
Случайно обнаружил 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.
Reply | Threaded
Open this post in threaded view
|

Re: TFFI

vvm13xyz xyz
Да, на слайдах ( 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.
Reply | Threaded
Open this post in threaded view
|

Re: TFFI

Denis Kudriashov

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

Как-то это требование не кажется реальным. Но, вероятно, я вас не так понимаю. Обычно в приложениях используется пул соединений, где разные потоки переиспользуют одни и те же объекты соединений. Я работал с ораклом через яву и http запросы явно проходили через пул. Может быть, глубоко внутри  jdbc-объекты оракла работали через специальный поток, но я не припомню чтобы профайлер это показывал.

Если все же верно то, что я говорю, то доступ к соединению просто должен быть синхронизирован. Для этого специальной поддержки VM не требуется. 
 
То бишь, если 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.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/sugr/CAG0zXM5av4aanU9puS1wvgVjZooU6Smvf-HaTJh81UX7Fx6TJQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: TFFI

Denis Kudriashov
In reply to this post by vvm13xyz xyz
пн, 31 авг. 2020 г. в 07:46, vvm13xyz xyz <[hidden email]>:
Случайно обнаружил 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).

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

Первая очень даже полезна. Threaded FFI может стоить очень дорого, например, для вызова большого кол-ва мат. функций в какой-нибудь либе.
Идея этих стратегий - это иметь возможность по разному выполнять FFI вызов в зависимости от нужд конкретного приложения. Первый подход требуется, когда необходима максимальная производительность.
 
третью я не очень понимаю, но по виду тоже бесполезна.

Третья стратегия это обязательное требование для MacOS и также, вероятно, для андроида. Там есть какие-то ограничения, откуда можно получать и обрабатывать события операционки. Для конечного пользователя это, вероятно, будет не нужно. 
Благодаря этой фиче мы получим полностью Idle Pharo, которая по-настоящему спит, если ничего не происходит, и аккумулятор не расходуется. Сейчас простаивающий имидж использует около 0.1-1% процессорного времени. TFMainThreadRunner - это конечно, не единственное, что для этого требуется, но необходимое.
 
Есть смысл говорить о второй, которая кажется чуть более перспективной, но лишь чуть.
Положим, есть Seaside-приложение. Без TFFI, если оно вызовет что-то долгоиграющее, зависнут все клиенты. Стратегия TFWorker, если работает только per library, приведёт примерно к тому же. Обращение к СУБД второго юзера станет в очередь и будет там находиться, пока обращение первого юзера не выполнится. Да, те процессы, которые не обращаются к базе, будут работать. Но поскольку каждое обращение к веб-странице порождает запрос к базе, все юзеры будут висеть.

Нет. Здесь все будет как надо. Можно будет сконфигурировать пул внешних  OS потоков для конкретных внешних вызовов. Точно не знаю детали и на какой оно стадии. Но ваш сценарий это именно то, что хотят здесь разрешить
 


--
--
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.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/sugr/CAG0zXM7%3DZ7er6ajRWDLvWFGjAYZ5hHwYWnfoF-PaqUiYTZpYKQ%40mail.gmail.com.