Pharo и многонитевый FFI

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

Pharo и многонитевый FFI

vvm13xyz xyz
Добрый день.

Решил рискнуть здоровьем и сделать то, что я сам же и осуждаю - задать вопрос без предварительного гугления и чтения ньюсгрупп. Но фаровы ньюсгруппы по-настоящему страшны, а ежедневного чтения настолько много, что ещё и на них меня не хватает..

Мне хочется соскочить с VW на Pharo (ввиду бесплатности последнего, чтобы убрать беспокойство по этому поводу). Но, что меня поражает, за все эти десятки лет (включая историю Squeak'а), полноценной поддержки (интересующих меня) СУБД так и не видно. Т.е. Oracle, DB2, Interbase/Firebird. Я не раз подумывал заняться сам. Если бы интерфейс к внешним вызовам был в духе VW или VAST'а, и занялся бы. Но вызовы FFI, как я читал, выполняется в той же нити, что и VM. Это сразу же убивает весь смысл. Для вебсервера это абсолютно неприемлемо. SQL-запросы могут выполняться достаточно продолжительное время, но при этом сервер не имеет права висеть, он должен отвечать на http-запросы других пользователей.

SqueakDBX сам по себе был сомнителен, но с многонитевостью они вообще провалились. Использование плагинов кажется мне чрезмерно сложным - это надо будет углублять около-C-шные знания и т.п., что само по себе может затянуться на месяцы, проще на VW оставаться.

Не так давно (но, наверное, год уже прошёл) я видел сообщение от Миранды, что он сделал многонитевый FFI. Как сейчас обстоят дела? Работоспособно ли оно? Есть ли более-менее приличная документация?

--
http://groups.google.ru/group/sugr
Reply | Threaded
Open this post in threaded view
|

Re: Pharo и многонитевый FFI

vmusulainen-2
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Pharo и многонитевый FFI

Dennis Schetinin
In reply to this post by vvm13xyz xyz
Я помню только про CogMT http://forum.world.st/Cog-vs-CogMT-td3926205.html. На его счет сообщались какие-то проблемки, но подробностей не знаю.


Best regards,
Dennis Schetinin
Sent with Sparrow

On Wednesday, 22 February 2012 г. at 0:37, Victor Metelitsa wrote:

Добрый день.

Решил рискнуть здоровьем и сделать то, что я сам же и осуждаю - задать вопрос без предварительного гугления и чтения ньюсгрупп. Но фаровы ньюсгруппы по-настоящему страшны, а ежедневного чтения настолько много, что ещё и на них меня не хватает..

Мне хочется соскочить с VW на Pharo (ввиду бесплатности последнего, чтобы убрать беспокойство по этому поводу). Но, что меня поражает, за все эти десятки лет (включая историю Squeak'а), полноценной поддержки (интересующих меня) СУБД так и не видно. Т.е. Oracle, DB2, Interbase/Firebird. Я не раз подумывал заняться сам. Если бы интерфейс к внешним вызовам был в духе VW или VAST'а, и занялся бы. Но вызовы FFI, как я читал, выполняется в той же нити, что и VM. Это сразу же убивает весь смысл. Для вебсервера это абсолютно неприемлемо. SQL-запросы могут выполняться достаточно продолжительное время, но при этом сервер не имеет права висеть, он должен отвечать на http-запросы других пользователей.

SqueakDBX сам по себе был сомнителен, но с многонитевостью они вообще провалились. Использование плагинов кажется мне чрезмерно сложным - это надо будет углублять около-C-шные знания и т.п., что само по себе может затянуться на месяцы, проще на VW оставаться.

Не так давно (но, наверное, год уже прошёл) я видел сообщение от Миранды, что он сделал многонитевый FFI. Как сейчас обстоят дела? Работоспособно ли оно? Есть ли более-менее приличная документация?

--
http://groups.google.ru/group/sugr

--
http://groups.google.ru/group/sugr
Reply | Threaded
Open this post in threaded view
|

Re: Pharo и многонитевый FFI

Denis Kudriashov
In reply to this post by vvm13xyz xyz
Привет

Насколько я знаю, SqueakDBX при обработки sql-запроса не блокирует виртуалку.
Здесь реализовано так же как с файлами.
Плагин squeakdbx передает в openDBX sql-запрос, регистрирует callback на него и тормозит смолтоковский процесс на семафоре. В этот момент виртуалка освобождается. Когда callback срабатывает плагин толкает семафор и процесс продолжает выполнение.

Но конечно стоит это проверить на практике.
И к тому же SqueakDBX поддерживает большинство баз данных и для него есть glorp

22 февраля 2012 г. 0:37 пользователь Victor Metelitsa <[hidden email]> написал:
Добрый день.

Решил рискнуть здоровьем и сделать то, что я сам же и осуждаю - задать вопрос без предварительного гугления и чтения ньюсгрупп. Но фаровы ньюсгруппы по-настоящему страшны, а ежедневного чтения настолько много, что ещё и на них меня не хватает..

Мне хочется соскочить с VW на Pharo (ввиду бесплатности последнего, чтобы убрать беспокойство по этому поводу). Но, что меня поражает, за все эти десятки лет (включая историю Squeak'а), полноценной поддержки (интересующих меня) СУБД так и не видно. Т.е. Oracle, DB2, Interbase/Firebird. Я не раз подумывал заняться сам. Если бы интерфейс к внешним вызовам был в духе VW или VAST'а, и занялся бы. Но вызовы FFI, как я читал, выполняется в той же нити, что и VM. Это сразу же убивает весь смысл. Для вебсервера это абсолютно неприемлемо. SQL-запросы могут выполняться достаточно продолжительное время, но при этом сервер не имеет права висеть, он должен отвечать на http-запросы других пользователей.

SqueakDBX сам по себе был сомнителен, но с многонитевостью они вообще провалились. Использование плагинов кажется мне чрезмерно сложным - это надо будет углублять около-C-шные знания и т.п., что само по себе может затянуться на месяцы, проще на VW оставаться.

Не так давно (но, наверное, год уже прошёл) я видел сообщение от Миранды, что он сделал многонитевый FFI. Как сейчас обстоят дела? Работоспособно ли оно? Есть ли более-менее приличная документация?

--
http://groups.google.ru/group/sugr

--
http://groups.google.ru/group/sugr
Reply | Threaded
Open this post in threaded view
|

Re: Pharo и многонитевый FFI

vvm13xyz xyz
In reply to this post by vmusulainen-2
Нет. Ни в VW, ни в VAST'е не то же самое. У Pharo/Squeak один клиент подвесит всех. Имидж не будет ни отвечать на http-запросы любых клиентов, ни перерисовывать GUI, пока SQL-запрос не отработает. Точнее, так подвиснут и VW с VAST'ом... если не использовать tthreaded API.У них-то он есть.

--
http://groups.google.ru/group/sugr
Reply | Threaded
Open this post in threaded view
|

Re: Pharo и многонитевый FFI

Denis Kudriashov
Но это связано с тем, что вызовы к базам данных реализованы через ffi , а на уровне плагинов есть возможность реализовывать асинхронные вызовы и не блокировать виртуалку

22 февраля 2012 г. 11:17 пользователь Victor Metelitsa <[hidden email]> написал:
Нет. Ни в VW, ни в VAST'е не то же самое. У Pharo/Squeak один клиент подвесит всех. Имидж не будет ни отвечать на http-запросы любых клиентов, ни перерисовывать GUI, пока SQL-запрос не отработает. Точнее, так подвиснут и VW с VAST'ом... если не использовать tthreaded API.У них-то он есть.

--
http://groups.google.ru/group/sugr

--
http://groups.google.ru/group/sugr
Reply | Threaded
Open this post in threaded view
|

Re: Pharo и многонитевый FFI

vvm13xyz xyz
In reply to this post by Denis Kudriashov
Это они обещали когда-то, что блокировать не будет. Потом я читал, что для Oracle у них это не работает. Поддержки DB2 нет. И сама по себе штука какая-то сомнительная.

--
http://groups.google.ru/group/sugr
Reply | Threaded
Open this post in threaded view
|

Re: Pharo и многонитевый FFI

vvm13xyz xyz
In reply to this post by Denis Kudriashov
И я уже в самом начале сказал, что использование плагинов для меня неприемлемо.

--
http://groups.google.ru/group/sugr
Reply | Threaded
Open this post in threaded view
|

Re: Pharo и многонитевый FFI

Dmitry Matveev
In reply to this post by vvm13xyz xyz
Добрый день.

По поводу FFI - основная проблема со старым (~до 2010г) FFI была в
том, что сама его реализация не была потокобезопасной - там
использовались статическая область памяти для чего-то, насколько я
помню из объяснений Элиота Миранды.

Я занимался портированием смолтоковой части GNU Smalltalk'ового FFI на
CogVM (и написанием плагина для VM с нуля). Его реализация по идее
является потокобезопасной, и поэтому мы сошлись на том, что вся
проблема сводится к поддержке виртуальной машиной нативных системных
потоков для реализации смолтоковых процессов. Этим занимался Элиот, но
попало ли  оно в основную ветку CogVM и когда - я, каюсь, упустил.

Чуть меньше года назад я пробовал перенести разработанное FFI на более
свежие версии CogVM, но, к сожалению, не смог довести дело до конца -
занят был. Сейчас как раз появляется возможность продолжить.

Что же касается SqueakDBX - Мариано говорил, что ему пришлось написать
отдельный плагин для VM, реализующий неблокирующие запросы к БД.

Дмитрий

--
http://groups.google.ru/group/sugr
Reply | Threaded
Open this post in threaded view
|

Re: Pharo и многонитевый FFI

vvm13xyz xyz
In reply to this post by vvm13xyz xyz
http://forum.world.st/Cog-vs-CogMT-td3926205.html - ну, это он, про него я и говорил, да. То есть, на 21-е октября оно так и не работало? ;-(

--
http://groups.google.ru/group/sugr
Reply | Threaded
Open this post in threaded view
|

Re: Pharo и многонитевый FFI

Denis Kudriashov
In reply to this post by vvm13xyz xyz
22 февраля 2012 г. 11:24 пользователь Victor Metelitsa <[hidden email]> написал:
Это они обещали когда-то, что блокировать не будет. Потом я читал, что для Oracle у них это не работает.
-- 

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

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

Не понимаю в чем здесь проблема. SqueakDBX - это пакет, реализованный через плагин. Но вам, как конечному пользователю, об этом думать не нужно. Загружаете пакет в образ, скачиваете бинарники для sqeakdbx/opendbx, и все должно работать.

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

Сейчас, кстати, squeakDBX переименован в DBXTalk. И на сайте должны быть бенчмарки

--
http://groups.google.ru/group/sugr
Reply | Threaded
Open this post in threaded view
|

Re: Pharo и многонитевый FFI

Denis Kudriashov
In reply to this post by vvm13xyz xyz
22 февраля 2012 г. 11:24 пользователь Victor Metelitsa <[hidden email]> написал:
Поддержки DB2 нет. И сама по себе штука какая-то сомнительная.

В таких случаях можно работать через ODBC.
Для этого также можно использовать OpenDBX.
Либо есть odbc пакет для фары/сквика

--
http://groups.google.ru/group/sugr
Reply | Threaded
Open this post in threaded view
|

Re: Pharo и многонитевый FFI

vvm13xyz xyz
In reply to this post by Denis Kudriashov
Я помню, что у них (SqueakDBX) на сайте была табличка, где асинхронность поддерживается, а где нет. Старый squeakdbx.org подарили сквоттерам, а новый DBXTalk.org не завели.

А посмотрите на http://www.linuxnetworks.de/doc/index.php/OpenDBX/C_API/Usage. Посмотрите, как предлагается в OpenDBX работаь с параметрами:

int len;
char query[256];
char qstr[] = "SELECT * FROM mytable WHERE uid = '%s'";

if( ( len = snprintf( query, 256, qstr, to ) ) > 0 && len < 256 )
{
    if( ( err = odbx_query( handle, query, len ) ) < 0 )
    {
        fprintf( stderr, "odbx_query(): %s\n", odbx_error( handle, err ) );
        return err;
    }
}

Это может казаться нормальным только то... не знаю даже, кому. Людям, которые с серьёзными базами данных и СУБД не работают.
Вопрос не только в опасности SQL injection (это можно обойти), но и в огромном вреде для производительности.
Должна быть возможность один раз за-prepare-ить statement с параметрами, затем его многократно вызывать.
Хранимые процедуры, опять же.

Предлагаемый пакет ODBC из той же оперы. Ну, я бы доработал его до приемлемого уровня, но "асинхронность"-то откуда взять?

--
http://groups.google.ru/group/sugr
Reply | Threaded
Open this post in threaded view
|

Re: Pharo и многонитевый FFI

Denis Kudriashov
Конечно, все неидеально.
Интересно, если ли более продвинутая альтернатива для мультиплатформенной работы с базами данных.

"Prepare statement", кстати, в следущей версии opendbx обещают добавить. Тем неменее, сомниваюсь, что в реальной системе использование "prepare statement" сильно влияет на производительность.


22 февраля 2012 г. 12:37 пользователь Victor Metelitsa <[hidden email]> написал:
Я помню, что у них (SqueakDBX) на сайте была табличка, где асинхронность поддерживается, а где нет. Старый squeakdbx.org подарили сквоттерам, а новый DBXTalk.org не завели.

А посмотрите на http://www.linuxnetworks.de/doc/index.php/OpenDBX/C_API/Usage. Посмотрите, как предлагается в OpenDBX работаь с параметрами:

int len;
char query[256];
char qstr[] = "SELECT * FROM mytable WHERE uid = '%s'";

if( ( len = snprintf( query, 256, qstr, to ) ) > 0 && len < 256 )
{
    if( ( err = odbx_query( handle, query, len ) ) < 0 )
    {
        fprintf( stderr, "odbx_query(): %s\n", odbx_error( handle, err ) );
        return err;
    }
}

Это может казаться нормальным только то... не знаю даже, кому. Людям, которые с серьёзными базами данных и СУБД не работают.
Вопрос не только в опасности SQL injection (это можно обойти), но и в огромном вреде для производительности.
Должна быть возможность один раз за-prepare-ить statement с параметрами, затем его многократно вызывать.
Хранимые процедуры, опять же.

Предлагаемый пакет ODBC из той же оперы. Ну, я бы доработал его до приемлемого уровня, но "асинхронность"-то откуда взять?

--
http://groups.google.ru/group/sugr

--
http://groups.google.ru/group/sugr
Reply | Threaded
Open this post in threaded view
|

Re: Pharo и многонитевый FFI

vvm13xyz xyz
Почитайте, к примеру, книги Тома Кайта, про Oracle. Да, компиляция одного SQL-выражения кажется совершенно безобидной. Подумаешь, малые доли секунды. Но когда это идёт потоком от многих пользователей, последствия ужасны (не преувеличиваю). Кайт это даже на простейших примерах демонстрирует. Одна из важнейших проблем - эта операция не параллелится на сервере Oracle. Т.е., когда один юзер компилирует SQL-выражение (hard parsing), другие не могут, хоть там 128 ядер. Но дела даже хуже, когда поток hard parsing идёт от всего двух юзеров, производительность с точки зрения одного падает куда более, чем вдвое, чем когда работает один. Для ораклистов это вообще общее место. Для DB2 дела обстоят несколько менее ужасно, но всё равно prepare рекомендуется (если не вспоминать о Static SQL).

Разумеется, здесь речь идёт о потоке быстровыполняющихся запросов, отличающихся параметрами (то, что характеризует вебсервер). Для небольшого количества очень медленно выполняющихся запросов, наоборот, выгодно использование литералов (прямая подстановка параметров), поскольку этим может воспользоваться оптимизатор.


--
http://groups.google.ru/group/sugr
Reply | Threaded
Open this post in threaded view
|

Re: Pharo и многонитевый FFI

vvm13xyz xyz
In reply to this post by Denis Kudriashov
Альтернатива? Делать, как в VW и VAST'е.

--
http://groups.google.ru/group/sugr
Reply | Threaded
Open this post in threaded view
|

Re: Pharo и многонитевый FFI

Denis Kudriashov
VW, как я понимаю, сами реализуют обертки к нативным провайдерам базданных.
Для такого проекта нужно много ресурсов. Поэтому и выбрали openDBX

22 февраля 2012 г. 13:59 пользователь Victor Metelitsa <[hidden email]> написал:
Альтернатива? Делать, как в VW и VAST'е.

--
http://groups.google.ru/group/sugr

--
http://groups.google.ru/group/sugr
Reply | Threaded
Open this post in threaded view
|

Re: Pharo и многонитевый FFI

vmusulainen-2
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Pharo и многонитевый FFI

Denis Kudriashov
In reply to this post by vvm13xyz xyz
22 февраля 2012 г. 13:57 пользователь Victor Metelitsa <[hidden email]> написал:
Почитайте, к примеру, книги Тома Кайта, про Oracle. Да, компиляция одного SQL-выражения кажется совершенно безобидной. Подумаешь, малые доли секунды. Но когда это идёт потоком от многих пользователей, последствия ужасны (не преувеличиваю). Кайт это даже на простейших примерах демонстрирует. Одна из важнейших проблем - эта операция не параллелится на сервере Oracle. Т.е., когда один юзер компилирует SQL-выражение (hard parsing), другие не могут, хоть там 128 ядер. Но дела даже хуже, когда поток hard parsing идёт от всего двух юзеров, производительность с точки зрения одного падает куда более, чем вдвое, чем когда работает один. Для ораклистов это вообще общее место. Для DB2 дела обстоят несколько менее ужасно, но всё равно prepare рекомендуется (если не вспоминать о Static SQL).

Разумеется, здесь речь идёт о потоке быстровыполняющихся запросов, отличающихся параметрами (то, что характеризует вебсервер). Для небольшого количества очень медленно выполняющихся запросов, наоборот, выгодно использование литералов (прямая подстановка параметров), поскольку этим может воспользоваться оптимизатор.


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

Вобщем не буду спорить, вам, несомненно, виднее. Просто удивлен.


--
http://groups.google.ru/group/sugr
Reply | Threaded
Open this post in threaded view
|

Re: Pharo и многонитевый FFI

Denis Kudriashov
In reply to this post by vmusulainen-2
22 февраля 2012 г. 14:39 пользователь Владимир Мусулайнен <[hidden email]> написал:
Я, конечно, понимаю, что черт, не мое дело... Но.
1. При планирующейся большой нагрузке еще узким местом будет
количество соединений с SQL-сервером. Их просто может на всех не
хватить. Так если столько пользователей лупит запросами, то как это
решать предполагается? Будут ждать очереди, пока из пула свободное
соединение отдадут?
2. Если серьезные базы, серьезная нагрузка, серьезные проекты. Вам не
страшно? Проект Pharo, конечно, неплохо развивается, но использовать
его в коммерции... Можно слишком много времени потратить на
допиливание. На фоне оракла, железа, стоимость лицензии VW просто
потеряется.


Я так понимаю, здесь рассматривается применение фары в веб решении.
В таких случая обычно используют связку с апачем, который осуществляет load balance и запускает требуемое кол-во экземпляров фары (даже на разных серверах)

 

--
http://groups.google.ru/group/sugr
123