Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
В очередной раз спасибо, Лёшка.
16.12.03 02:32 Число просмотров: 1542
Автор: void <Grebnev Valery> Статус: Elderman
|
В очередной раз спасибо, Лёшка.
> Хм, насколько я знаю, для надежной работы пула потоков (в
> том числе в системах реального времени) нонче модно
> использовать так называемый watchdog, который регулярно
> извещается самим потоками о том, что эти потоки живы.
Признаюсь, я просто не смотрел сабдж. И раз ты говоришь, что это хорошо, то я соглашусь, ибо прислушиваюсь к "старшим" ;)) (без иронии. я серьёзно)
> Порядок
> действий в этом случае такой: рабочий поток произвольным
> образом (например, через UDP) извещает следящий процесс о
> том, что этот рабочий поток жив. Если следящий процесс в
> течение определенного времени не получает сигнала от
> рабочего потока, он прибивает рабочий поток (скажем, через
> kill(SIGKILL)), и перезапускает
> новый поток - преемника убитого. Такой способ быстрее, чем
> предложенный, и не требует взаимной синхронизации за
> исключением механизма посылания сообщения.
Да в принципе что-то схожее и предлагалось. Не как альтернатива;)).
Ибо я вообще не знал, что есть профессиональные решения на эту тему. Как всегда в моём маленьком мегаполисе изобретаю велосипеды;)) Нет самокаты;)))
Не могу согласится (сразу) только с тем, что в описанном алгоритме будет долго. Там ж не мьютексов, не хрютексов. Критическая секция очень быстрая (по сравнению с остальным). В ней пара операций. Дёрнули и отпустили. Хотя ... может я и не прав.
> Ну а какие тут могут быть идеи... Не использовать же thread
> local storage. А раз не использовать, то из многочисленных
> соображений (фрагментация памяти, производительность выдачи
> и освобождения памяти и проч.) лучше написать свой менеджер
> памяти, который и будет заниматься организацией всего этого
> безобразия. Алгоритм работы менеджера целиком и полностью
> зависит от конкретного приложения и даже от конкретных
> условий работы этого приложения.
Это было б сложно для того контекста ("из спортивного интереса"), который здесь. А если честно - мне и недоступно. Программист я - сам знаешь какой. Но всё равно интересно;)).
> В отдельном-то потоке зачем? Ставим
> select, а для keep-alive-сигналов
> либо создаем специальный формат сообщения, который будет
> отлавливаться еще до передачи в рабочие потоки, либо
> открываем дополнительное соединение, по которому только
> кипалайвы и шлются.
Дык, и мне не хочется в отдельном потоке;)) Я ж пишу - изврат. Да, может и на selecte. Всё равно, там надо думать.
А про формат keepalive сообщения - дык это уже сделано в том протоколе "для затравки";))) Всё пока правда криво, ибо делалось в несколько дней "на скоряк".
> > компилировать отдельно. Там (на платформах отличных
> от
> > Intel) и учесть можно – делать htons, или нет. Другие
> > мнения есть?
> Есть. Зачем выбирать, делать или не делать htons, если
> можно всегда его делать?
Обоснуй. Это ж не смтп и фтп, т.е. то, что оговорено RFC. Какой смысл соблюдать сетевой порядок байт только в заголовке прикладного протокола. Тогда и все числовые значения, что длиной более одного байта, и которые следуют за заголовком прикладного протокола - придётся в сетевом порядке представлять.
Пожалуйста, обоснуй. То, что на сетевом и транспортных уровнях так - нет вопросов. Но я не пойму, зачем это в прикладном протоколе для DBMS?
> По-моему, это не имеет большого значения. А поле
> reserved лучше иметь всегда.
Зачем тогда гуру обманывают начинающих, как я? ;)))
> Актуально, но не в нашем случае. Это интересно для
> выжимания производительности на локальной машине, а когда
> появляется сеть и/или доступ к БД... Характерные времена
> уже не те, чтобы это было заметно. ИМХО.
Про производительность согласен. Но! Если компиллер не вставит дополнительный код (за спиной программера) при доступе к невыровненным данным, то на некоторых процеках это приводит к ошибкам, как говорят гуру. Сам не встречал. Как думаешь?
> checksum.
> Требует. "Нам не дано предугадать", в каком месте наш софт
> слетит. И не стоит уповать на вылизанность кода, тем более
> что потери производительности действительно никакой.
Вот блин! Хоть это я сделал правильно;))
И здесь мне приятно, что ты поддержал меня, Лёшка. А то "импортные" только обзываться умеют. ;)))
|
|
|
подробно о проекте
Анализ криптографических сетевых...
