В Stackless нет. Прерваться может только на моменте, когда тасклет добровольно отдаёт управление планировщику. Точнее, есть ещё режим вытесняющей многозадачности, когда можно по счётчику инструкций отбирать управление у тасклета, но к внешним по отношению к Python функциям это не относится.
Выигрыш чего перед чем? Пост про Python, в общем-то. Если Java умеет поставить зелёный поток в слип на ожидании ввода-вывода, а когда надо разбудить, то это же здорово. Это как раз и есть та же технология, про которую я писал.
В принципе, так делают. Манкипатчат вызовы функций socket и подставляют вместо них «асинхронные» версии. Теоретически ничего этому не мешает, но практически нормальной реализации нет, которая различает блокирующий и неблокирующий режимы, умеет понимать разницу между read(buf, 1024) — «прочитай 1024 или можешь не возвращаться» и «прочитай хоть сколько-нибудь, но не больше 1024».
Что касается Erlang, то это отличный язык, от рождения сделанный асинхронным. Единственная проблема — его применение в коммерческом проекте. Где найти знающих его программистов? С Python попроще будет.
Его хотели портировать под Stackess в рамках Google Summer of Code, но не портировали. Почему — не знаю, кстати. То ли заявку не приняли, то ли не сделал никто.
Принципиально ничем, только производительность выше. Для примера посмотрите на функцию get(), которую я привёл в посте. В многопоточной программе, чтобы избежать race condition, нужно было бы завернуть тело функции в мьютекс. В Stackless оно не надо, ибо многозадачность кооперативная.
Я начал работать шивой, ещё когда студентом был. Так хотел устроиться на работу, что на собеседовании размахивал руками и рассказывал, как я смогу всё автоматизировать, как выжму из компьютеров максимум; что сотрудники смогут заниматься только своей работой, а не рутиной и уж, тем более, не войнами с техникой. В общем, продавался, как мог. Потом прошло время и пришлось выполнять данные обещания…
Кроме собственно администрирования виндов на рабочих станциях и зоопарка серверов, написал кучу велосипедов: заточенную под бизнес CRM, потом к ней прикрутил модуль логистики, затем и все продажи вместе бухучётом переехали в мою систему, написал свою систему хелпдеска с веб-интерфейсом для клиентов, где саппорт видел и перечень установленного оборудования, и версии софта, и рекомендации производителей, и сроки гарантийного обслуживания.
Где-то в середине процесса закончил институт и смог больше времени тратить на работу: настроил asterisk так, чтобы при определившемся номере клиента его автоматически переключало на нужного менеджера, а у последнего автоматически открывался профиль клиента; написал систему складского учёта, включая программирование носимых терминалов с радиосвязью, перевел весь склад (20 сотрудников) на штрихкодирование. Невероятное количество технологий, протоколов, взаимодействий — всё изучалось на одном дыхании, стандарты и документация читались от корки до корки тоннами. Из техники выжималось всё, что могло хоть как-то помочь бизнесу.
А потом всё, как отрезало. Надоел сумасшедший режим работы, взрыв мозга, нехватка времени на собственное развитие, понимание, что это ненормальное развитие ИТ-системы на предприятии. Ведь, несмотря на сложность созданных решений, они были сделаны совсем не так, как могли быть: отсутствовала вменяемая документация, использовались старые подходы к программированию, изобретались зачастую неэффективные велосипеды, многое делалось на соплях и скотче. Если бы я не брался за всё сразу, то результатом могли бы стать более качественно сделанные системы. Сейчас мне стыдно смотреть в глаза администраторам и программистам (их, к слову, трое меня заменяют), которые всё это хозяйство теперь обслуживают.
Выводы:
1. роль шивы может как увеличить количество его собственных знаний, так может и не увеличить — всё зависит от подхода к работе. При умелом подходе к работе, выгоду из неё извлекают и работодатель, и сам сотрудник;
2. роль шивы совершенно точно заставляет мозг работать, разбираться в нестандартных ситуациях, анализировать и сопоставлять. В целом развивать интеллект — и это стопроцентный плюс для самого шивы;
3. будучи шивой, невозможно всё сделать качественно в силу отсутствия времени. Скотч и сопли — лучшие друзья шивы;
4. руководитель, нанимающий шиву, экономит много денег в краткосрочной перспективе. Главное — вовремя его остановить и не дать ему испортить перспективу долгосрочную.
Атака «человек посередине» не имеет никакого отношения ни к фишингу, ни к фармингу. Человеком посередине может быть ваш интернет-провайдер (например, там работает злобный админ, которому хочется почитать вашу бухгалтерию, посмотреть ваши номера кредиток и т.д.), может быть злобный работодатель (которому ужас как интересно, чем занимаются сотрудники в рабочее время) и т.д.
Злоумышленник перехватывает ваши запросы на 443 порт, подпихивая вам свой самоподписанный сертификат на тот домен, на который вы хотите зайти, сам в это время создает запрос на настоящий сервер и пересылает его ответ вам. Ваш браузер честно показывает страничку, только ругается, что сертификат выдан не известным вам удостоверяющим центром, а каким-то левым. Текстом там может быть написано, что угодно, что это Verisign, Thawte, название домена буковка в буковку совпадает — все там в порядке будет, только вот браузер будет честно предупреждать, что это может быть ненастоящий сайт.
Кстати, упомянутые тут WebMoney недавно купили себе wildcard-сертификат на *.webmoney.ru, просто еще не везде успели поставить.
Согласен. Это костыли, заменяющие полноценную экономическую конкуренцию. Для отдельного человека это отличная мотивация, а вот для бизнеса, который обладает ресурсами для каких-то более масштабных вложений в исследования, авторитет имеет вторичную ценность. Первична все-таки прибыль.
По поводу торможения прогресса я вот что думаю. С одной стороны, да — ограничения в использовании идей мешают прогрессу. Это отлично иллюстрируется научным сообществом. Если бы учёные не встречались на конференциях, не писали бы публикации и не рассказывали максимально широко о своих исследованиях, наука развивалась бы намного медленнее. При открытом обмене информацией любой учёный может опереться на то, что уже исследовано, а не исследовать это заново. Если бы за каждое использование чужого исследования приходилось платить, развитие бы замедлилось. Но у науки есть одно важное отличие от коммерческих исследований — за неё платит государство. Цель государства — улучшение жизни всех граждан, а не извлечение прибыли, и поэтому оно готово тратить свои деньги на зарплату учёным, невзирая на то, что их результатами воспользуются граждане других стран.
С коммерческими исследованиями другая ситуация. Каждый организация будет делать то, что позволит ей извлечь максимальную прибыль. Она не заботится о прогрессе всего человечества. Возникает вопрос — как государству в этих условиях построить патентное законодательство, чтобы «локальный эгоизм» каждой компании работал на благо всего человечества? Резонный ответ — позволить заработать изобретательством. Компания вкладывает деньги в исследования, если она может потом их результатами воспользоваться. И чем больше она денег сможет заработать, тем больше денег будет тратить на исследования. Да, потом результаты исследований будут воплощаться в более дорогие товары для потребителей. Но чудес не бывает — если не потребитель явно из своего кошелька оплачивает новые исследования, то это должно делать государство, платя зарплату учёным. Из наших кошельков в виде налогов, причём.
А в этом все и дело. Конечно, патентовать идеи — это правильно. Это стимулирует изобретательство и прогресс в целом. Это хорошо глобально для всего человечества. Только из-за невозможности отличить, что можно патентовать, а что нельзя, и возникают казусы. «Патентовать рыбалку» — это нельзя, а «патентовать рыбалку определенной наживкой в определенном месте» — можно? Я не могу представить себе формулировку закона, которая проведет границу между тем, что можно, и тем, что нельзя. Конечно, приведённый мной пример утрирован, но в целом ситуация именно такая, какая есть. Сортировку не запатентуешь — ей уже много лет пользуются, конкретный алгоритм запатентовать можно, так как это уже реализация, которую можно блок-схемой нарисовать. А где граница — а бог его знает.
В мире пробовали и запрещать патентовать идеи (у нас) и разрешать патентовать все идеи (у них). У нас изобретателем быть невыгодно, у них бесконечные судебные процессы за «право рыбачить». И мне кажется, что правильнее все-таки второй способ. В каждом конкретном судебном иске на каждом судебном заседании истец и ответчик пытаются провести грань между «можно» и «нельзя». А иначе не будет прогресса — изобретателям (программистам, математикам и т.д.) ведь тоже кушать хочется.
try: with Timeout.push(10): do_something_heavy() except TimeoutError: do_some_recovery()А API-функцию в асинхронной программе вы не прервёте. Пока она выполняется, другой код всё равно управление не получит.
Что касается Erlang, то это отличный язык, от рождения сделанный асинхронным. Единственная проблема — его применение в коммерческом проекте. Где найти знающих его программистов? С Python попроще будет.
conn = HTTPConnection() сonn.connect(("hostname", 80)) try: req = conn.post("/path/name", data) req.add_header("Content-type", "multipart/form-data") req.add_header("Content-length", len(data)) res = conn.perform(req) finally: conn.close()Всё будет отлично работать впараллель.
И да, после reboot не помешает поплясать с бубном, пока пинг не восстановится.
Кроме собственно администрирования виндов на рабочих станциях и зоопарка серверов, написал кучу велосипедов: заточенную под бизнес CRM, потом к ней прикрутил модуль логистики, затем и все продажи вместе бухучётом переехали в мою систему, написал свою систему хелпдеска с веб-интерфейсом для клиентов, где саппорт видел и перечень установленного оборудования, и версии софта, и рекомендации производителей, и сроки гарантийного обслуживания.
Где-то в середине процесса закончил институт и смог больше времени тратить на работу: настроил asterisk так, чтобы при определившемся номере клиента его автоматически переключало на нужного менеджера, а у последнего автоматически открывался профиль клиента; написал систему складского учёта, включая программирование носимых терминалов с радиосвязью, перевел весь склад (20 сотрудников) на штрихкодирование. Невероятное количество технологий, протоколов, взаимодействий — всё изучалось на одном дыхании, стандарты и документация читались от корки до корки тоннами. Из техники выжималось всё, что могло хоть как-то помочь бизнесу.
А потом всё, как отрезало. Надоел сумасшедший режим работы, взрыв мозга, нехватка времени на собственное развитие, понимание, что это ненормальное развитие ИТ-системы на предприятии. Ведь, несмотря на сложность созданных решений, они были сделаны совсем не так, как могли быть: отсутствовала вменяемая документация, использовались старые подходы к программированию, изобретались зачастую неэффективные велосипеды, многое делалось на соплях и скотче. Если бы я не брался за всё сразу, то результатом могли бы стать более качественно сделанные системы. Сейчас мне стыдно смотреть в глаза администраторам и программистам (их, к слову, трое меня заменяют), которые всё это хозяйство теперь обслуживают.
Выводы:
1. роль шивы может как увеличить количество его собственных знаний, так может и не увеличить — всё зависит от подхода к работе. При умелом подходе к работе, выгоду из неё извлекают и работодатель, и сам сотрудник;
2. роль шивы совершенно точно заставляет мозг работать, разбираться в нестандартных ситуациях, анализировать и сопоставлять. В целом развивать интеллект — и это стопроцентный плюс для самого шивы;
3. будучи шивой, невозможно всё сделать качественно в силу отсутствия времени. Скотч и сопли — лучшие друзья шивы;
4. руководитель, нанимающий шиву, экономит много денег в краткосрочной перспективе. Главное — вовремя его остановить и не дать ему испортить перспективу долгосрочную.
Оно дешево в производстве и быстро выходит из строя, провоцируя этим новые продажи.
Злоумышленник перехватывает ваши запросы на 443 порт, подпихивая вам свой самоподписанный сертификат на тот домен, на который вы хотите зайти, сам в это время создает запрос на настоящий сервер и пересылает его ответ вам. Ваш браузер честно показывает страничку, только ругается, что сертификат выдан не известным вам удостоверяющим центром, а каким-то левым. Текстом там может быть написано, что угодно, что это Verisign, Thawte, название домена буковка в буковку совпадает — все там в порядке будет, только вот браузер будет честно предупреждать, что это может быть ненастоящий сайт.
Кстати, упомянутые тут WebMoney недавно купили себе wildcard-сертификат на *.webmoney.ru, просто еще не везде успели поставить.
С коммерческими исследованиями другая ситуация. Каждый организация будет делать то, что позволит ей извлечь максимальную прибыль. Она не заботится о прогрессе всего человечества. Возникает вопрос — как государству в этих условиях построить патентное законодательство, чтобы «локальный эгоизм» каждой компании работал на благо всего человечества? Резонный ответ — позволить заработать изобретательством. Компания вкладывает деньги в исследования, если она может потом их результатами воспользоваться. И чем больше она денег сможет заработать, тем больше денег будет тратить на исследования. Да, потом результаты исследований будут воплощаться в более дорогие товары для потребителей. Но чудес не бывает — если не потребитель явно из своего кошелька оплачивает новые исследования, то это должно делать государство, платя зарплату учёным. Из наших кошельков в виде налогов, причём.
В мире пробовали и запрещать патентовать идеи (у нас) и разрешать патентовать все идеи (у них). У нас изобретателем быть невыгодно, у них бесконечные судебные процессы за «право рыбачить». И мне кажется, что правильнее все-таки второй способ. В каждом конкретном судебном иске на каждом судебном заседании истец и ответчик пытаются провести грань между «можно» и «нельзя». А иначе не будет прогресса — изобретателям (программистам, математикам и т.д.) ведь тоже кушать хочется.