Re: Анонсы докладов 3-й конференции по F irebird
"Alexey Popov" сообщил/сообщила в новостях следующее: И как будет выглядеть этот модуль? Который должен быть универсальным. А как выглядит тот-же асинхронный АДО, АДО.НЕТ? Он не может вернуть курсор в другой поток, т. к. при разборе результата даже простой isc_fetch должен выполнится асинхронно, т.к. может заброкироваться надолго. В результате бизнес-логику надо размазывать по двум потоком - основным и потоком работающим с БД. А почему размазывание бизнес-логики не происходит при асинхронном использовании сокетов? Наверное потому, что при асинхронном использовании сокетов, приложение изначально проектируется соответствующим образом. И ещё, ИМХО, мы имеем отсутствие аснхронности ещё и потому, что никакие компоненты прямого доступа не приспособленны к асинхронным операциям и для нормальной работы нужно писать свои компоненты, ориентированные именно на асинхронный режим работы или использовать breafcase для работы пользователя, попутно заполняя его результатами асинхронных операций. И не нужно говорить об асинхронности как о панацее, это как и всякий инструмент, кому-то будет к месту, а кому-то нет. :)
Re: Анонсы докладов 3 -й конференции по Firebird
Игорь Горбонос wrote: И чесно говоря я не понимаю, почему нельзя сделать для себя модуль, который будет асинхронно выполняить запросы к БД, если есть такая необходимость? И как будет выглядеть этот модуль? Который должен быть универсальным. Он не может вернуть курсор в другой поток, т. к. при разборе результата даже простой isc_fetch должен выполнится асинхронно, т.к. может заброкироваться надолго. В результате бизнес-логику надо размазывать по двум потоком - основным и потоком работающим с БД.
Re: Анонсы докладов 3-й конференции по F irebird
"Alexey Popov" сообщил/сообщила в новостях следующее: Было: первый поток работает с железом, второй работает в БД. Стало: один поток работает и с железом и с БД. А когда мы работали с теми-же платами Диалоджика, делали именно так как "Было" и именно в парадигме event-driven programing :) Потому, что в уровне работы с устройством, нафиг не нужна была работа с базой, а на уровне работы с базой не нужны возможности работы с устройством. И это наверное было следствием особенностей предметной области И чесно говоря я не понимаю, почему нельзя сделать для себя модуль, который будет асинхронно выполняить запросы к БД, если есть такая необходимость?
Re[2]: Анонсы докладов 3-й конференции по Firebird
Привет! > Начал за здравие, кончил за упокой. > Асинхронность ввода вывода как раз позволяет уменьшить количество > потоков и избавится от кошмарной синхронизации. > Было: первый поток работает с железом, второй работает в БД. > Стало: один поток работает и с железом и с БД. > rtfm event-driven programing Это у тебя всё в диск упирается, а у меня куча логики в БД - соответственно, мне асинхронность нафиг не нужна :) > Минус в том, что в таком подходе усложняется код из за необходимости > мыслить в терминах теории конечных автоматов и сложности с декомпозицией. Вот и я о том же. Асинхронность хороша, когда у тебя нет кучи ядер. >> А без многопоточности в эпоху мультиядерности >> оно нафиг никому не впилось. > Это ты суперсервер так ловко подколол ? :) Я супер в его нынешнем виде не использую, бо воне не распараллеливаеццо. А вот правильный супер - очень даже буду. :) З.Ы. Если кому-то интересно моё мнение - то я считаю, что в крайнем случае можно реализовать HTTP-обёртку рядом со своим собственным демоном и делать всё, что душе заблагорассудится. Но если очень сильно припечёт - то можно и свой libfbclient написать. С блэкджеком и далее по тексту. -- Best regards, Sergeymailto:gebele...@gmail.com
Re: Анонсы докладов 3 -й конференции по Firebird
Khorsun Vlad wrote: Ну написать клиента на какую либо платформу. Каких платформ тебе не хватает ? Где *масса* применений ? Как ты думаешь, почему ява и нет клиенты не хотят использовать gds32.dll и ходят напрямую по сокетам? Почему? Зачем им этот секс? Сейчас эти клиенты на птичьих правах т.к. используют реверс-инженеринг недокументирванного протокола. А пользуют эти клиенты тысячи. Вот тебе и ответ на вопрос о количестве заинтересованных лиц. Если им это надо, то можешь поверить что и многим другим это надо. Да ну? В существующее api асинхронные возможности встроить практически невозможно, не перелопатив его всего. Конечно, лучше писать новый велосипед, не вникая в старый. Тут уже плакались что старое API не позволяет ввести длинные идентификаторы для объектов в БД. Наверняка аналогичный косяк кстати может всплыть и на уровне протокола. Совместимость со старыми клиентами никто не отменял. Клянёшься? А то тут уже намудрили, когда переход от F1.0 и выше происходит с большим скрипом из за проблем с обратной совместимостью. Потом, хоп, скажут, что для работы с FB X.Y клиент от FB 1.0 уже не прокатит и нужно обновить клиента.
Re: Анонсы докладов 3 -й конференции по Firebird
Sergey Mereutsa wrote: Так вот. Асинхронность, скажу я вам, штука зело вкусная, ежели её применять правильно. Особенно, когда у тебя работа с девайсом, у которого на борту 4 войсовых процессора и 30 войсовых каналов, которые ты в цикле опрашиваешь и вся работа с которыми - это работа с событиями на этих каналах. Но - как же без этого - есть у неё одна бааальшая ж%па при работе в многопоточной среде - в виде кошмара синхронизации тредов, запутанности и непонятности для простого человеческого процесса мышления. Начал за здравие, кончил за упокой. Асинхронность ввода вывода как раз позволяет уменьшить количество потоков и избавится от кошмарной синхронизации. Было: первый поток работает с железом, второй работает в БД. Стало: один поток работает и с железом и с БД. rtfm event-driven programing Минус в том, что в таком подходе усложняется код из за необходимости мыслить в терминах теории конечных автоматов и сложности с декомпозицией. А без многопоточности в эпоху мультиядерности оно нафиг никому не впилось. Это ты суперсервер так ловко подколол ? :)
Re[2]: Ну шо, дождались?
Привет! >> З.Ы. Влад, а что, ту бяку с live-lock-ом решили так и оставить? Или мы >> про неё никому не скажем? > Мы про неё думаем усиленно. В принципе, можно и в трекер её - потом > всё равно придётся :) Занести мне или ты сам занесёшь? -- Best regards, Sergeymailto:gebele...@gmail.com
