Да щас то че, стыдиться нечего. Луценко сидит. Тимошенко сидит. Оппозиция скуплена/запугана. Тишь да гладь.
Литература, опять же, развивается невиданными темпами. Буквально миллионы баксов типографии писателям выплачивают.
Для незнакомых с архитектурой CouchDB, ближайший аналог из мира SQL — обновление индексов при добавлении записи. Представьте себе, что вы создали пару десятков сложных индексов по паре десятков длинных варчар или текст полей, где обычно все поля пустые кроме нескольких. И тут добавили запись, где все поля заполнены данными максимальной длины. И обновление такой записи заняло больше 5 сек.
Так яснее?
На самом деле в обработчике доступен только номер сигнала.
Общая схема предполагается такой: при старте нити она получает порядковый номер. Далее управляющая нить решает, что какую-то, скажем третью, нить нужно остановить. Тогда она в стоп-векторе третий бит ставит в один и вызывает сигнал. В обработчике ничего не происходит. Все нити в состоянии чтения выходят из функции с состоянием EINTR. Нити проверяют наличие флага в векторе, третья завершается, остальные перезапускают функцию чтения.
Зачем усложнять простые вещи. Флаги по определению thread safe. Устанавливаются только в обработчике прерываний, треды его только читают. Обычного статического инта, массива вполне достаточно.
Слово «вектор» я использовал в классическом значении — массив, без привязки к конкретной реализации.
В простейшем случае, когда нитей немного, это может быть простой инт. Если тредов больше, чем разрядность целевой машины, это будет массив.
На класс памяти никаких ограничений на самом деле нет. Конечно, логично разместить его статически, но даже если пришла фантазия разместить его в куче — да пожалуйста, главное сделать это при старте до настройки обработки сигналов.
Запросто, на питоне. Фактически это таже таблица переходов. Только без излишних сложностей в ее интерпретации, да и работать будет раза в два быстрее.
state = 'INIT'
while state != 'QUIT':
symbol = read_input()
if state == 'INIT':
if symbol == '*':
doIntroduce()
state = 'INIT'
elif symbol == 'LOGIN':
doLogin()
state = 'SESSION'
elif symbol == 'EXIT':
doQuit()
state = 'QUIT'
elif state == 'STORE':
if symbol == '*':
doRemember()
state = 'STORE'
elif symbol == 'EXIT':
state = 'SESSION'
elif state == 'SESSION':
if symbol == 'SAY':
doSay()
state = 'SESSION'
elif symbol == '*':
state = 'SESSION'
elif state == 'MEMORIZE':
state = 'STORE'
elif state == 'EXIT':
state = 'INIT'
Подход питона более практичен. Очевидно же, что представление строки в виде списка символов неоптималено ни по расходу памяти ни по скорости типичных алгоритмов. Питоновская строка только «похожа» на список, то есть она реализует почти те же интерфейсы, что и список. Отличия только в том, что елементами строки могут быть только символы, и строки неизменяемы. Но это только интерфейсы, внутренняя реализация абсолютно другая.
Один из интерфейсов строки — iterable. Именно это может привести к такой трудно обнаруживаемой ошибке.
def do_something(names):
for name in names:
do(name)
Предполагается, что вызывать будут в виде: do_something(['name1', 'name2'])
Если по ошибке вызвать: do_something('name'), то вызов прекрасно отработает, только
do() будет вызвано с 'n', 'a' и так далее.
Это почему это? Уровней вложенностей будет ровно два: внешний свитч по входному символу, и внутренние свитчи по состоянию автомата (можно наоборот).
По виду это почти не отличается от приведенной в статье таблицы переходов.
Есть одна неприятная ситуация, когда вместо списка передают строку, а она успешно обрабатывается как список символов.
Бывает очень увлекательно ловить такую багу.
Сам не люблю «языкосрач», но «ресипт» это за гранью добра и зла. Есть же русское «рецепт», ну ладно, не нравится — возьми английское «рисайп». Ну ладно, не сложилось с произношением — ну «рисип». Но «Т» там откуда?!!!
Какой ресипт?!!!
Литература, опять же, развивается невиданными темпами. Буквально миллионы баксов типографии писателям выплачивают.
И да, я тоже их люблю.
Во-вторых — это аналогия, она, как обычно, хромает, но представление о сути дела — дает.
Так яснее?
Общая схема предполагается такой: при старте нити она получает порядковый номер. Далее управляющая нить решает, что какую-то, скажем третью, нить нужно остановить. Тогда она в стоп-векторе третий бит ставит в один и вызывает сигнал. В обработчике ничего не происходит. Все нити в состоянии чтения выходят из функции с состоянием EINTR. Нити проверяют наличие флага в векторе, третья завершается, остальные перезапускают функцию чтения.
В простейшем случае, когда нитей немного, это может быть простой инт. Если тредов больше, чем разрядность целевой машины, это будет массив.
На класс памяти никаких ограничений на самом деле нет. Конечно, логично разместить его статически, но даже если пришла фантазия разместить его в куче — да пожалуйста, главное сделать это при старте до настройки обработки сигналов.
state = 'INIT' while state != 'QUIT': symbol = read_input() if state == 'INIT': if symbol == '*': doIntroduce() state = 'INIT' elif symbol == 'LOGIN': doLogin() state = 'SESSION' elif symbol == 'EXIT': doQuit() state = 'QUIT' elif state == 'STORE': if symbol == '*': doRemember() state = 'STORE' elif symbol == 'EXIT': state = 'SESSION' elif state == 'SESSION': if symbol == 'SAY': doSay() state = 'SESSION' elif symbol == '*': state = 'SESSION' elif state == 'MEMORIZE': state = 'STORE' elif state == 'EXIT': state = 'INIT'def do_something(names): for name in names: do(name)Один из интерфейсов строки — iterable. Именно это может привести к такой трудно обнаруживаемой ошибке.
def do_something(names):
for name in names:
do(name)
Предполагается, что вызывать будут в виде: do_something(['name1', 'name2'])
Если по ошибке вызвать: do_something('name'), то вызов прекрасно отработает, только
do() будет вызвано с 'n', 'a' и так далее.
Везде можно найти способ прострелить себе ногу.
По виду это почти не отличается от приведенной в статье таблицы переходов.
Очередной виток спирали.
Бывает очень увлекательно ловить такую багу.
Какой ресипт?!!!