Re[2]: Ну шо, дождались?

Привет! З.Ы. Влад, а что, ту бяку с live-lock-ом решили так и оставить? Или мы про неё никому не скажем? Мы про неё думаем усиленно. В принципе, можно и в трекер её - потом всё равно придётся :) Занести мне или ты сам занесёшь? -- Best regards, Sergey

Re: Анонсы докладов 3 -й конференции по Firebird

Sergey Mereutsa wrote: Так вот. Асинхронность, скажу я вам, штука зело вкусная, ежели её применять правильно. Особенно, когда у тебя работа с девайсом, у которого на борту 4 войсовых процессора и 30 войсовых каналов, которые ты в цикле опрашиваешь и вся работа с которыми - это работа с

Re: Анонсы докладов 3 -й конференции по Firebird

Khorsun Vlad wrote: Ну написать клиента на какую либо платформу. Каких платформ тебе не хватает ? Где *масса* применений ? Как ты думаешь, почему ява и нет клиенты не хотят использовать gds32.dll и ходят напрямую по сокетам? Почему? Зачем им этот секс? Сейчас эти клиенты на птичьих

Re[2]: Анонсы докладов 3-й конференции по Firebird

Привет! Начал за здравие, кончил за упокой. Асинхронность ввода вывода как раз позволяет уменьшить количество потоков и избавится от кошмарной синхронизации. Было: первый поток работает с железом, второй работает в БД. Стало: один поток работает и с железом и с БД. rtfm event-driven

Re: Анонсы докладов 3-й конференции по F irebird

Alexey Popov сообщил/сообщила в новостях следующее: Было: первый поток работает с железом, второй работает в БД. Стало: один поток работает и с железом и с БД. А когда мы работали с теми-же платами Диалоджика, делали именно так как Было и именно в парадигме event-driven programing :)

Re: Анонсы докладов 3 -й конференции по Firebird

Игорь Горбонос wrote: И чесно говоря я не понимаю, почему нельзя сделать для себя модуль, который будет асинхронно выполняить запросы к БД, если есть такая необходимость? И как будет выглядеть этот модуль? Который должен быть универсальным. Он не может вернуть курсор в другой поток, т.