Здравствуйте, Курилка, Вы писали:
К>Забавный финт обнаружили в эрланговом мейллисте К>Эрланг — тоже верёвка достаточной длины чтобы выстрелить себе в ногу
А можешь обрисовать, в чём конкретно там заподло?
Казалось бы, процесс Tick не взаимодействует с мега-функцией надругательства над списками.
Или же в эрланговской машине за паттерн-матчинг отвечает какой-то синглетон, не сериализующий доступ процессов к себе родимому?
К>Или же в эрланговской машине за паттерн-матчинг отвечает какой-то синглетон, не сериализующий доступ процессов к себе родимому?
Ulf Wiger
It was mentioned in another post that pattern-matching is atomic in the VM. That's correct — the VM will not schedule another process while inside a pattern match (except, of course, in the SMP version, where other schedulers might).
В другом сообщении было отмечено, что сопоставление с образцом является атомарной операцией в VM. Так и есть — VM не будет планировать выполнение других процессов, пока производится выполнение сопоставления(за исключением версии SMP, в которой другие планировщики могут продолжать работу)
Здравствуйте, Кодт, Вы писали:
К>А можешь обрисовать, в чём конкретно там заподло? К>Казалось бы, процесс Tick не взаимодействует с мега-функцией надругательства над списками. К>Или же в эрланговской машине за паттерн-матчинг отвечает какой-то синглетон, не сериализующий доступ процессов к себе родимому?
Основной сиглетон там — эрланговая ВМ, которая есть 1 процесс с т.зр. ОС (не с т.зр. эрланговой ВМ).
Собственно Мамут всё правильно написал.
Здравствуйте, Кодт, Вы писали:
К>Или же в эрланговской машине за паттерн-матчинг отвечает какой-то синглетон, не сериализующий доступ процессов к себе родимому?
Эрланговская машина — она однопоточная (в первом приближении). И паттерн-матчинг внутри интерпретатора реализован как обычная нативная функция. Со всеми вытекающими последствиями.
Здравствуйте, Mamut, Вы писали:
К>>Или же в эрланговской машине за паттерн-матчинг отвечает какой-то синглетон, не сериализующий доступ процессов к себе родимому?
M>В другом сообщении было отмечено, что сопоставление с образцом является атомарной операцией в VM. Так и есть — VM не будет планировать выполнение других процессов, пока производится выполнение сопоставления(за исключением версии SMP, в которой другие планировщики могут продолжать работу)
Офигеть!!! То есть, если в сопоставлении участвуют два мегасписка (AList=BList), то виртуальная машина уходит курить?
А это косяк конкретной реализации машины, или косяк спецификации языка?
Ведь, по большому счёту, кому здесь нужна атомарность?
Здравствуйте, Кодт, Вы писали:
К>Офигеть!!! То есть, если в сопоставлении участвуют два мегасписка (AList=BList), то виртуальная машина уходит курить?
Уходит, куда она денется-то...
К>А это косяк конкретной реализации машины, или косяк спецификации языка? К>Ведь, по большому счёту, кому здесь нужна атомарность?
Ну вроде спецификации как таковой нету (насколько я знаю), там ISO или типа того
Насколько я понимаю фактически рантайм дискретизирует выполнение процессов по редукциям. Т.е. любой кусок функции, который не вызывает других функций будет выполняться атомарно.
Здравствуйте, Кодт, Вы писали:
К>Офигеть!!! То есть, если в сопоставлении участвуют два мегасписка (AList=BList), то виртуальная машина уходит курить?
Угу. На практике просто такое не встречается часто.
К>А это косяк конкретной реализации машины, или косяк спецификации языка? К>Ведь, по большому счёту, кому здесь нужна атомарность?
Это банальный недостаток реализации. Атомарный алгоритм PM написать очень просто — я слабо представляю как там его переписать в прерываемый вид.
В принципе, если был бы нормальный JIT — можно было бы сделать PM в виде управляемого кода. Было бы проще.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Кодт, Вы писали:
К>>Офигеть!!! То есть, если в сопоставлении участвуют два мегасписка (AList=BList), то виртуальная машина уходит курить? C>Угу. На практике просто такое не встречается часто.
К>>А это косяк конкретной реализации машины, или косяк спецификации языка? К>>Ведь, по большому счёту, кому здесь нужна атомарность? C>Это банальный недостаток реализации. Атомарный алгоритм PM написать очень просто — я слабо представляю как там его переписать в прерываемый вид.
C>В принципе, если был бы нормальный JIT — можно было бы сделать PM в виде управляемого кода. Было бы проще.
Только для этого надо переделывать рантайм (вводить уровень управляемого кода), или можно что-нибудь типа хаскельного заюзать, только тоже передалывать рантайм.
Здравствуйте, Курилка, Вы писали:
C>>В принципе, если был бы нормальный JIT — можно было бы сделать PM в виде управляемого кода. Было бы проще. К>Только для этого надо переделывать рантайм (вводить уровень управляемого кода), или можно что-нибудь типа хаскельного заюзать, только тоже передалывать рантайм.
Код на Erlang'е сейчас и есть "управляемым". Просто делать паттерн-матчинг на интерпретируемом языке — это убиться об стену.
А нормальный JIT всё равно когда-нибудь нужен будет.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Курилка, Вы писали:
C>>>В принципе, если был бы нормальный JIT — можно было бы сделать PM в виде управляемого кода. Было бы проще. К>>Только для этого надо переделывать рантайм (вводить уровень управляемого кода), или можно что-нибудь типа хаскельного заюзать, только тоже передалывать рантайм. C>Код на Erlang'е сейчас и есть "управляемым". Просто делать паттерн-матчинг на интерпретируемом языке — это убиться об стену.
Дык о том и речь, что для решения такой проблемы нужен другой управляемый язык.
C>А нормальный JIT всё равно когда-нибудь нужен будет.
Ну за 20 лет пока не понадобился, с джитом это уже имхо будет не эрланг, а другой язык, хотя конкретно не скажу в чём может проявиться разница, могу врать.
Здравствуйте, Курилка, Вы писали:
C>>Код на Erlang'е сейчас и есть "управляемым". Просто делать паттерн-матчинг на интерпретируемом языке — это убиться об стену. К>Дык о том и речь, что для решения такой проблемы нужен другой управляемый язык.
Совсем необязательно. Достаточно сделать, чтобы Erlang-код компилировался в низкоуровневый байт-код (по типу C#/Java), в котором прямо можно записать алгоритм PM.
C>>А нормальный JIT всё равно когда-нибудь нужен будет. К>Ну за 20 лет пока не понадобился, с джитом это уже имхо будет не эрланг, а другой язык, хотя конкретно не скажу в чём может проявиться разница, могу врать.
Нормальные JITы просто не так давно появились. А целиком переделывать Erlang никому не хочется.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Курилка, Вы писали:
C>>>Код на Erlang'е сейчас и есть "управляемым". Просто делать паттерн-матчинг на интерпретируемом языке — это убиться об стену. К>>Дык о том и речь, что для решения такой проблемы нужен другой управляемый язык. C>Совсем необязательно. Достаточно сделать, чтобы Erlang-код компилировался в низкоуровневый байт-код (по типу C#/Java), в котором прямо можно записать алгоритм PM.
Т.е. низкоуровневый байт-код это не есть другой управляемый язык?
C>Нормальные JITы просто не так давно появились. А целиком переделывать Erlang никому не хочется.
Здравствуйте, Кодт, Вы писали:
M>>В другом сообщении было отмечено, что сопоставление с образцом является атомарной операцией в VM. Так и есть — VM не будет планировать выполнение других процессов, пока производится выполнение сопоставления(за исключением версии SMP, в которой другие планировщики могут продолжать работу)
К>Офигеть!!! То есть, если в сопоставлении участвуют два мегасписка (AList=BList), то виртуальная машина уходит курить?
А ты, прежде чем фигеть, сначала приведи пример задачи, где в сопоставлении будут участвовать два мегасписка. У меня почему-то фантазии не хватает, и у разработчиков Erlang VM — тоже в свое время не хватило (иначе бы подумали о том, как прервать сопоставление с образцом), и за последние 10 лет эксплуатации production-систем на Эрланге никто не жаловался на дикие блокировки рантайма. И ведь знаешь, что интересно — после обсуждения этой дури в erlang mail-list никто даже дефекта не открыл .
К>А это косяк конкретной реализации машины, или косяк спецификации языка?
Это что. А еще Эрланг VM можно дико затормозить создав много-много ets таблиц, пока не переполнится память. А представляешь, какой косяк в спецификации языка — ты можешь создать два процесса, каждый из которых посылает друг другу в два раза больше сообщений, чем получил. Что приведет к переполнению очередей, и Жопе. Ух, косяк-то какой, косячище просто .
К>Ведь, по большому счёту, кому здесь нужна атомарность?
Угу, ща все бросим, будем прерывание паттерн матчинга обеспечивать.
Здравствуйте, Gaperton, Вы писали:
К>>Офигеть!!! То есть, если в сопоставлении участвуют два мегасписка (AList=BList), то виртуальная машина уходит курить? G>А ты, прежде чем фигеть, сначала приведи пример задачи, где в сопоставлении будут участвовать два мегасписка.
Например, в результате бага.
G>У меня почему-то фантазии не хватает, и у разработчиков Erlang VM — тоже в свое время не хватило (иначе бы подумали о том, как прервать сопоставление с образцом), и за последние 10 лет эксплуатации production-систем на Эрланге никто не жаловался на дикие блокировки рантайма. И ведь знаешь, что интересно — после обсуждения этой дури в erlang mail-list никто даже дефекта не открыл .
Так а смысл открывать-то? Это не бага, это фича такая.
К>>А это косяк конкретной реализации машины, или косяк спецификации языка? G>Это что. А еще Эрланг VM можно дико затормозить создав много-много ets таблиц, пока не переполнится память.
А почему он будет тормозить? Я так не пробовал делать, но вроде причин для тормозов не должно быть. Ну кроме внешних, типа излишнего свопинга.
G>А представляешь, какой косяк в спецификации языка — ты можешь создать два процесса, каждый из которых посылает друг другу в два раза больше сообщений, чем получил. Что приведет к переполнению очередей, и Жопе. Ух, косяк-то какой, косячище просто .
Это не косяк — эти два процесса не будут мешать остальным процессам. Ну только если вся память совсем не закончится, что тоже сделано в Erlang'е не самым лучшим образом.
К>>Ведь, по большому счёту, кому здесь нужна атомарность? G>Угу, ща все бросим, будем прерывание паттерн матчинга обеспечивать.
На самом деле, было бы неплохо. Только лучше в комплекте с добавлением нормального JITа, иначе особого смысла оно само по себе не имеет.
Здравствуйте, Gaperton, Вы писали:
G>А ты, прежде чем фигеть, сначала приведи пример задачи, где в сопоставлении будут участвовать два мегасписка. У меня почему-то фантазии не хватает, и у разработчиков Erlang VM — тоже в свое время не хватило (иначе бы подумали о том, как прервать сопоставление с образцом), и за последние 10 лет эксплуатации production-систем на Эрланге никто не жаловался на дикие блокировки рантайма. И ведь знаешь, что интересно — после обсуждения этой дури в erlang mail-list никто даже дефекта не открыл .
Я тоже сперва думал, что паттерн-матчинг с мегасписком — это пальцы отвалятся писать.
Но ведь мегасписком может быть пользовательская строка, приехавшая откуда-нибудь извне.
К>>А это косяк конкретной реализации машины, или косяк спецификации языка? G>Это что. А еще Эрланг VM можно дико затормозить создав много-много ets таблиц, пока не переполнится память. А представляешь, какой косяк в спецификации языка — ты можешь создать два процесса, каждый из которых посылает друг другу в два раза больше сообщений, чем получил. Что приведет к переполнению очередей, и Жопе. Ух, косяк-то какой, косячище просто .
Если переполнение очереди сообщений пользовательского процесса убивает всю виртуальную машину — это косяк.
К>>Ведь, по большому счёту, кому здесь нужна атомарность? G>Угу, ща все бросим, будем прерывание паттерн матчинга обеспечивать.
Не хочешь — не надо. Я просто не знаю масштаб бедствия — почему атомарность ПМ является фундаментальной. Это прихоть, или на неё что-то ещё завязано?
Насколько я понимаю (возможно, заблуждаюсь), ПМ состоит из 3 частей применительно к каждому паттерну:
1) сопоставление структуры паттерна (как он записан!) со структурой аргумента;
2) связывание переменных;
3) сравнение значений в соответствующих узлах структуры паттерна и аргумента; а также проверка условий в guard sequence.
Все претензии по мегасписку — к последнему пункту. Но в нём ведь мы ничего "специального" не делаем, почему бы не выполнять проверки в обычном темпе?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
К>>>Офигеть!!! То есть, если в сопоставлении участвуют два мегасписка (AList=BList), то виртуальная машина уходит курить? G>>А ты, прежде чем фигеть, сначала приведи пример задачи, где в сопоставлении будут участвовать два мегасписка. C>Например, в результате бага.
Бага — это хорошая, полезная, очень практическая задача . Ты не мог бы привести пример задачи, в которой эта бага хотя бы теоретически может проявится?
К>>>А это косяк конкретной реализации машины, или косяк спецификации языка? G>>Это что. А еще Эрланг VM можно дико затормозить создав много-много ets таблиц, пока не переполнится память. C>А почему он будет тормозить? Я так не пробовал делать, но вроде причин для тормозов не должно быть. Ну кроме внешних, типа излишнего свопинга.
Своппинг и будет. Например — в результате бага.
G>>А представляешь, какой косяк в спецификации языка — ты можешь создать два процесса, каждый из которых посылает друг другу в два раза больше сообщений, чем получил. Что приведет к переполнению очередей, и Жопе. Ух, косяк-то какой, косячище просто . C>Это не косяк — эти два процесса не будут мешать остальным процессам. Ну только если вся память совсем не закончится, что тоже сделано в Erlang'е не самым лучшим образом.
Да ты что — это же самый настоящий косяк спецификации языка!
К>>>Ведь, по большому счёту, кому здесь нужна атомарность? G>>Угу, ща все бросим, будем прерывание паттерн матчинга обеспечивать. C>На самом деле, было бы неплохо. Только лучше в комплекте с добавлением нормального JITа, иначе особого смысла оно само по себе не имеет.
Чем тебя не устраивает HiPE? Зачем нужен именно JIT?
Здравствуйте, Gaperton, Вы писали:
C>>Например, в результате бага. G>Бага — это хорошая, полезная, очень практическая задача . Ты не мог бы привести пример задачи, в которой эта бага хотя бы теоретически может проявится?
Просто сложный PM по большому списку. Хотя тоже не так просто получить это...
C>>А почему он будет тормозить? Я так не пробовал делать, но вроде причин для тормозов не должно быть. Ну кроме внешних, типа излишнего свопинга. G>Своппинг и будет. Например — в результате бага.
Со свопингом можно (и нужно!) бороться. Про удивительно плохую работу Erlang'а в условиях недостатка памяти тут уже писали.
C>>Это не косяк — эти два процесса не будут мешать остальным процессам. Ну только если вся память совсем не закончится, что тоже сделано в Erlang'е не самым лучшим образом. G>Да ты что — это же самый настоящий косяк спецификации языка!
Это конкретно — нет.
G>>>Угу, ща все бросим, будем прерывание паттерн матчинга обеспечивать. C>>На самом деле, было бы неплохо. Только лучше в комплекте с добавлением нормального JITа, иначе особого смысла оно само по себе не имеет. G>Чем тебя не устраивает HiPE?
Ну тормозит он, тормозит.
G>Зачем нужен именно JIT?
Потому, что я не могу из-за тормознутости использовать Erlang на моих устройствах. А так хотелось бы — там вообще идеальная для него задача.
Здравствуйте, Cyberax, Вы писали:
G>>>>Угу, ща все бросим, будем прерывание паттерн матчинга обеспечивать. C>>>На самом деле, было бы неплохо. Только лучше в комплекте с добавлением нормального JITа, иначе особого смысла оно само по себе не имеет. G>>Чем тебя не устраивает HiPE? C>Ну тормозит он, тормозит.
G>>Зачем нужен именно JIT? C>Потому, что я не могу из-за тормознутости использовать Erlang на моих устройствах. А так хотелось бы — там вообще идеальная для него задача.
Поставим вопрос так — а почему ты думаешь, что JIT будет лучше чем HiPE?
Здравствуйте, Cyberax, Вы писали:
C>>>Например, в результате бага. G>>Бага — это хорошая, полезная, очень практическая задача . Ты не мог бы привести пример задачи, в которой эта бага хотя бы теоретически может проявится? C>Просто сложный PM по большому списку. Хотя тоже не так просто получить это...
Например, читаем имена из файла, в котором случилась проблема с разметкой.
И дальше — хотя бы сортируем список этих имён.
Каждое сравнение элементов атомарно (по крайней мере, для наивной реализации, не ждущей заподлянки от пользователя).
Паттерны простейшие, и список небольшой. Всего из двух строк...
Перекуём баги на фичи!
