http://habrahabr.ru/post/154419/#habracut
не Н2

Здравствуйте, <Аноним>, Вы писали:

А>http://habrahabr.ru/post/154419/#habracut
А>не Н2
Это даже не смешно.
Ибо немерле по сравнению с этим позволяет делать на порядки меньше работы.

Здравствуйте, WolfHound, Вы писали:

WH>Ибо немерле по сравнению с этим позволяет делать на порядки меньше работы.
В каком смысле? Насколько я понял эта штука — monkey patching для .net, что вроде бы ортогонально тому что делает nemerle.

Здравствуйте, Аноним, Вы писали:

А>http://habrahabr.ru/post/154419/#habracut
А>не Н2

Мне кто-то объяснит, зачем делать что-то в рантайме, если это можно сделать в компайлтайме?

Здравствуйте, <Аноним>, Вы писали:

WH>>Ибо немерле по сравнению с этим позволяет делать на порядки меньше работы.
А>В каком смысле? Насколько я понял эта штука — monkey patching для .net, что вроде бы ортогонально тому что делает nemerle.
Теоритически можно решать те же задачи. И судя по заголовку именно на это и намек.
Но решение будет настолько сложным что

Здравствуйте, hardcase, Вы писали:

H>Мне кто-то объяснит, зачем делать что-то в рантайме, если это можно сделать в компайлтайме?
Вот например, забавная библиотека для питона — https://github.com/sitesupport/gevent
Условно говоря, патчатся стандартные фнукции и методы типа read и sleep, в результате там где поток обычно ждал окончания синхронной операции может продолжиться выполнение какой-либо другой. В результате имеем простой для чтения (без колбэков для асинхронных операций) и эффективный код (https://github.com/zacharyvoase/gevent-threading-comparison).

Здравствуйте, Аноним, Вы писали:

А>Условно говоря, патчатся стандартные фнукции и методы типа read и sleep, в результате там где поток обычно ждал окончания синхронной операции может продолжиться выполнение какой-либо другой. В результате имеем простой для чтения (без колбэков для асинхронных операций) и эффективный код (https://github.com/zacharyvoase/gevent-threading-comparison).

Я не просил примера полезности сабжа. Читаем внимательно:

H>>Мне кто-то объяснит, зачем делать что-то в рантайме, если это можно сделать в компайлтайме?

Приведенный пример тривиально решается как в нынешнем Nemerle, так и в грядущем C#5.0, безо всякого патчинга статическим образом.

Здравствуйте, hardcase, Вы писали:

H>Приведенный пример тривиально решается как в нынешнем Nemerle, так и в грядущем C#5.0, безо всякого патчинга статическим образом.
каким образом? monkey-patching он ведь заменяет в рантайме стандартные методы используемые в том числе и например библиотечным кодом.
Т.е. если есть например сторонняя прослойка, общающаяся с базой данных через read, по после такого патча её работа станет асинхронной.

Здравствуйте, Аноним, Вы писали:

PostSharp делает не тоже самое только один раз после компиляции?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, hardcase, Вы писали:

H>>Приведенный пример тривиально решается как в нынешнем Nemerle, так и в грядущем C#5.0, безо всякого патчинга статическим образом.
А>каким образом? monkey-patching он ведь заменяет в рантайме стандартные методы используемые в том числе и например библиотечным кодом.

Таким что сразу пишется асинхронный код, который выглядит "синхронно".

А>Т.е. если есть например сторонняя прослойка, общающаяся с базой данных через read, по после такого патча её работа станет асинхронной.

Угу, и появляются невероятные глюки потому как код затачивался на синхронную работу.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, hardcase, Вы писали:

H>>Приведенный пример тривиально решается как в нынешнем Nemerle, так и в грядущем C#5.0, безо всякого патчинга статическим образом.
А>каким образом? monkey-patching он ведь заменяет в рантайме стандартные методы используемые в том числе и например библиотечным кодом.
А>Т.е. если есть например сторонняя прослойка, общающаяся с базой данных через read, по после такого патча её работа станет асинхронной.

Мне кажется, что я чего-то не понимаю в этой жизни.
Как можно сделать синхронный код использующий read асинхронным просто подменив этот read? Или авторы просто придумали какой-то аналог "портов завершения" для интерпретатора? Т.е. физический поток интерпретатора освобождается для каких-то других действий в то время как логический поток находится в состоянии ожидания. Если это так, то это просто оптимизация питонячьего рантайма а никакое не превращение синхронного кода в асинхронный — ведь логический поток блокирован!

А>http://habrahabr.ru/post/154419/#habracut

Блин, хабр открыл америку и снова упал в моих глазах EasyHook хоть и штука нужная иногда, но ей сто лет в обед! Гугл ".net code injection" выводит на неё и пару подобных с первой страницы. Первые релизы именно её наверное ещё в 2006-м были, что-ли. Её применяют ну в совсем других целях. Бывает весь проект на один синглтон завязан, и ради запуска юнит-тестов нужно туда другой код впихнуть. Бывает надо быстро патч к какому-нить контролу или либке сделать, у которой исходников нет, а авторы забыли что-то нужное. Бывает в BCL косяк, и нужно фиксить быстро, решительно, потому что MS ничего не исправляет, только новое дописывает. Бывает платить за какую-то хрень, нужную только раз и прям щаз лениво, а захачить её пара минут, (тот же рефлектор, например). Но рассматривать это как средство программирования или метапрограммирования — вы уж извините, но это вопиющее непонимание разницы подходов. По вашей логике получается что официальной прародитель этой штуки — Detours — убийца метапрограммирования на шаблонах в C++?? А в форуме cpp всё ещё спят спокойно, не знают бедные...

А>Условно говоря, патчатся стандартные фнукции и методы типа read и sleep, в результате там где поток обычно ждал окончания синхронной операции может продолжиться выполнение какой-либо другой. В результате имеем простой для чтения (без колбэков для асинхронных операций) и эффективный код (https://github.com/zacharyvoase/gevent-threading-comparison).

А ты читал что они там реально делают? Например они неспроста тестируют код изначально многопоточный, завязанный на старт множества потоков. А знаешь почему это тормозит _до_ накатывания их патчей?

Здравствуйте, hardcase, Вы писали:
H>Угу, и появляются невероятные глюки потому как код затачивался на синхронную работу.
Я же написал "забавная" библиотека. Действительно, есть в таком подходе нечто безумное, но самое забавное, что прекрасно работает.
Я бы сам никогда не поверил если бы не не увидел своими глазами на работающем сервере.

H>Как можно сделать синхронный код использующий read асинхронным просто подменив этот read?
В превом приближении, есть операция epoll, которая по набору дескрипторов может сказать что по одному из них готовы данные, т.е. read вместо ожидания на одном дескрипторе ожидает сразу на всех и после чтения продолжает выполнение соответствующего кода.

H>это просто оптимизация питонячьего рантайма а никакое не превращение синхронного кода в асинхронный — ведь логический поток блокирован!
Логический поток блокирован в любом случае, потому что для продолжения работы ему нужны данные которых ещё нет. Если бы это был классический асинхронный вызов, то он выглядел бы как beginread(callback) — логическое продолжение потока в callback также заблокировано до завершения чтения.

Наверное более простым примером по теме было бы логирование. Представь, что можно переопределить write для стандартного сокета, и автоматом собирать весь трафие черех какие-бы библиотеки он не шёл.

Здравствуйте, hi_octane, Вы писали:

_>А ты читал что они там реально делают? Например они неспроста тестируют код изначально многопоточный, завязанный на старт множества потоков. А знаешь почему это тормозит _до_ накатывания их патчей?

Ну не они первые дошли до мысли, что реализация высконкуретного сервера с упором на ввод-вывод гораздо эффективнее на зелёных потоках.

Но если например сравнивать код на node.js:

    socket.on('data', function(data) {
        buffer.push(data);
        ...
    });

    socket.on('end', function() {
        ...
    });

И на питоне с gevent:

    while True:
       data = file.read(buf_size)
       if data:
           buffer += bytes
       else:
           break

То невооружённым глазом заметно ради чего всё затевалось.

Здравствуйте, Аноним, Вы писали:

А>То невооружённым глазом заметно ради чего всё затевалось.

Теперь загугли async/await из C#. И никакого патчинга.

Здравствуйте, hardcase, Вы писали:

H>Теперь загугли async/await из C#. И никакого патчинга.
И как ты в read применишь await если это синхронный метод и возвращет набор данных? А если там не read, а какой-нибудь service_proxy.execute_request из сторонней библиотеки? Код в моём же примере выглядит как абсолютно однопоточный, вся магия включается после импорта gevent.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, hardcase, Вы писали:

H>>Теперь загугли async/await из C#. И никакого патчинга.
А>И как ты в read применишь await если это синхронный метод и возвращет набор данных? А если там не read, а какой-нибудь service_proxy.execute_request из сторонней библиотеки? Код в моём же примере выглядит как абсолютно однопоточный, вся магия включается после импорта gevent.

Если мне нужно асинхронное поведение, то я буду использовать соответствующие функции и библиотеки.

Здравствуйте, hardcase, Вы писали:

H>Если мне нужно асинхронное поведение, то я буду использовать соответствующие функции и библиотеки.
Хорошо. Но ты изначально хотел узнать, зачем это может понадобиться.
Я привёл любопытный вариант с которым работал на практике. Если даже более простой пример с логированием не устраивает, то я даже не знаю с чем ещё сравнить. Это как забаклассить окно в винде — подменить оконную процедуру и возможно вызывать оригинальную, только такой фокус можно проворачивать с чем угодно.

Здравствуйте, hardcase, Вы писали:

H>Мне кто-то объяснит, зачем делать что-то в рантайме, если это можно сделать в компайлтайме?

Тестирование, навесные защиты, динамический анализ кода и т.п. Короче, когда исходники недоступны, либо их нельзя изменить/собрать. В том же [Tool] Code Perspective

Автор: kochetkov.vladimir
Дата: 01.10.12

используется этот подход, только сборка патчится не в памяти, а на диске и немного другим способом.

Применять это непосредственно при разработке кода — смысла не имеет, IMO.