Как только однопоточной программе, обслуживающей в цикле десять тысяч клиентов, приходится ради одного из них задержаться, например, на секунду, эту секунду ждут все остальные
1) событийные программы не однопоточны: обычно используется пул потоков.
2) для длительных подзапросов используются отдельные пулы потоков на каждую подсистему (БД, диски, сеть), в т.ч. с добавлением потоков по требованию. Во многих случаях API к таким пулам предоставляются ОСью.
С учетом 1 и 2, единственным недостатком событийной модели остается относительная сложность программирования если в инструменте нет поддержки co-routines.
Я использую музыку для непрерывного сосредоточения на задаче.
Вот требования к такой музыке, которая помогает, а не мешает:
1) Музыка должна нравиться
2) Вокала не должно быть (исключение — на незнакомых языках)
3) Все треки должны быть хорошо знакомы многие годы (никакого радио).
4) Каждый раз альбомы и треки должны проигрываться в том же самом порядке (никакого шаффла)
5) Плейлист должен быть составлен сразу на все время работы над задачей.
6) Желательно для разных одновременных проектов использовать непересекающиеся наборы треков.
При выполнении этих условий возникает привязка музыки к кодированию — условный рефлекс, который при прослушивании плейлиста постоянно возвращает мысли в нужное русло :)
По поводу shared_ptr — это не так в случае полиморфизма, поскольку тогда он объявляется для абстрактного класса, а ссылается на конкретные объекты, и остаются все те же проблемы, что и с обычным указателем.
А откуда про массовость проблемы известно?
Ни squid ни другие популярные прокси сервера такой уязвимости как transparent cache poisoning (из-за игнорирования DNS) не содержат, иначе она давно стала бы известна безо всяких веб сокетов.
Прозрачный прокси должен выполнять серверные запросы к IP в который резолвится заголовок Host.
Если он вместо этого использует оригинальный IP назначения клиентского соединения, то это уязвимость конкретного прокси.
Причем здесь Web sockets? Вероятно уязвимость в чем то другом.
И слава богу, что на всякую чушь не тратят свои девелоперские ресурсы.
Кому-то шашечки а кому то ехать.
Вот в Eclipse этот прогресс показывается, а простейшее действие implement method в CDT (среда для С++) занимает десятки секунд. То же относится к любому С++ рефакторингу.
Поэтому я до сих пор софт даже для линукса и GCC пишу в VS под виндой.
Например мобилки Philips серии Xenium имеют время работы без зарядки не меньше двух недель, а в ожидании и до месяца (при стандартных емкостях батареи до 1ач).
При этом аналогичные по функциональности сотовые от большинства других производителей держат не больше недели.
Это показывает что на самом деле производителям мобильных устройств есть огого еще куда оптимизировать энергопотребление.
Я просто не хотел привлекать внимание фанатов единой точки выхода :))
А так — да. Когда писал, не сразу вписал pos = NULL. Но опыт не пропьешь :) Краем глаза заметил что чего-то не хватает и добавил.
Впрочем с return тоже не все ветки можно обработать, т.ч. тут скорее личные предпочтения и опыт играют роль, а не потенциальная проблемность техники.
До этого ни разу не писал бинарный поиск — использовал библиотечные реализации языков.
10 мин — первый вариант
потом 5 минут мысленного тестирования — обнаружил один баг — добавил + 1 для правой ветки поиска.
И вот: pastie.org/927876
Касательно типичных ошибок.
Если использовать указатели, а не индексирование массива, то практически не используется ни одна конструкция приводящая к этим ошибкам.
Мне например никогда бы не пришло в голову находить средний указатель путем (a+b)/2 поскольку операция сложения для указателей бессмысленна. А вот вычитание и сложение с числом — типичный шаблон применения указателей: a + (b — a)/2
Много упрощения в коде дает обозначение конца интервала не последним его элементом, а следующим за ним. Т.е. длина интервала end — begin, а не end — begin + 1.
К сожалению, это только один из многих частных случаев.
В_И_А_Г_Р_А
Виа(гра)
ВИ/\ГР/\
Не говоря уже о том, что много спама валит без прямого указания там ключевых слов.
Пока компы не научатся понимать смысл текста (читай: пока не будет создан ИИ), спамеры всегда смогут придумать как обойти подобные фильтры.
Но все равно спасибо, что занимаетесь этой темой. Надо держать спамеров в тонусе :)
1) событийные программы не однопоточны: обычно используется пул потоков.
2) для длительных подзапросов используются отдельные пулы потоков на каждую подсистему (БД, диски, сеть), в т.ч. с добавлением потоков по требованию. Во многих случаях API к таким пулам предоставляются ОСью.
С учетом 1 и 2, единственным недостатком событийной модели остается относительная сложность программирования если в инструменте нет поддержки co-routines.
Вот требования к такой музыке, которая помогает, а не мешает:
1) Музыка должна нравиться
2) Вокала не должно быть (исключение — на незнакомых языках)
3) Все треки должны быть хорошо знакомы многие годы (никакого радио).
4) Каждый раз альбомы и треки должны проигрываться в том же самом порядке (никакого шаффла)
5) Плейлист должен быть составлен сразу на все время работы над задачей.
6) Желательно для разных одновременных проектов использовать непересекающиеся наборы треков.
При выполнении этих условий возникает привязка музыки к кодированию — условный рефлекс, который при прослушивании плейлиста постоянно возвращает мысли в нужное русло :)
Но, как уже рядом ответили, в большинстве случаев такая оптимизация срабатывает.
Спасибо, не знал.
Ни squid ни другие популярные прокси сервера такой уязвимости как transparent cache poisoning (из-за игнорирования DNS) не содержат, иначе она давно стала бы известна безо всяких веб сокетов.
Если он вместо этого использует оригинальный IP назначения клиентского соединения, то это уязвимость конкретного прокси.
Причем здесь Web sockets? Вероятно уязвимость в чем то другом.
см. VisualAssist, например
Кому-то шашечки а кому то ехать.
Вот в Eclipse этот прогресс показывается, а простейшее действие implement method в CDT (среда для С++) занимает десятки секунд. То же относится к любому С++ рефакторингу.
Поэтому я до сих пор софт даже для линукса и GCC пишу в VS под виндой.
При этом аналогичные по функциональности сотовые от большинства других производителей держат не больше недели.
Это показывает что на самом деле производителям мобильных устройств есть огого еще куда оптимизировать энергопотребление.
Так шо рано гнать на акуммуляторы, успеется :)
А так — да. Когда писал, не сразу вписал pos = NULL. Но опыт не пропьешь :) Краем глаза заметил что чего-то не хватает и добавил.
Впрочем с return тоже не все ветки можно обработать, т.ч. тут скорее личные предпочтения и опыт играют роль, а не потенциальная проблемность техники.
10 мин — первый вариант
потом 5 минут мысленного тестирования — обнаружил один баг — добавил + 1 для правой ветки поиска.
И вот:
pastie.org/927876
Касательно типичных ошибок.
Если использовать указатели, а не индексирование массива, то практически не используется ни одна конструкция приводящая к этим ошибкам.
Мне например никогда бы не пришло в голову находить средний указатель путем (a+b)/2 поскольку операция сложения для указателей бессмысленна. А вот вычитание и сложение с числом — типичный шаблон применения указателей: a + (b — a)/2
Много упрощения в коде дает обозначение конца интервала не последним его элементом, а следующим за ним. Т.е. длина интервала end — begin, а не end — begin + 1.
Для этого только SSH доступ нужен на обоих узлах.
Из сеанса на хостинге:
scp backup.tgz user@remotehost:/path/to/backup.tgz
Или из сеанса на удаленном хосте (куда копировать надо):
scp user@hostingip:/path/to/backup.tgz backup.tgz
В_И_А_Г_Р_А
Виа(гра)
ВИ/\ГР/\
Не говоря уже о том, что много спама валит без прямого указания там ключевых слов.
Пока компы не научатся понимать смысл текста (читай: пока не будет создан ИИ), спамеры всегда смогут придумать как обойти подобные фильтры.
Но все равно спасибо, что занимаетесь этой темой. Надо держать спамеров в тонусе :)