Ну если мы пишем безопасный язык (например Rust), то мы можем заставить компилятор проверять флаговый регистр после каждой арифметической операции. Судя по приведенному ассемблерному коду, Rust так и делает.
А если мы пишем на чем-то типа С, то у нас есть целая куча либо быстрых, либо переносимых способов.
Да, действительно. Тут я ошибся. SIGFPE это thread-directed сигнал.
Но всё равно, сигнал либо придет асинхронно и тогда попробуй обработай его правильно. Исключение то нельзя бросить из обработчика. Только хардкор, только longjmp что подходит только для C и то с большими оговорками.
А если обратывать сигнал синхронно, то проще уж проверять делитель или флаговый регистр, так хоть переключений контекста не будет.
И ещё небольшое дополнение: прерывание при целочисельном делени на ноль возникается кажется только в x86. Например, arm просто записывает 0 в качестве результата и всё. Стандарт C говорит что результат деления на 0 будет undefined, если не ошибаюсь.
Это кажется довольно логичным, потому что процессор не должен заниматься валидацией обрабатываеммых данных. А исключение при делении на 0 — это рудимент эпохи программируемых калькуляторов.
При переполнении процессор выставляет бит переноса в флаговом регистре. Приложение может проверить его, если оно опасается переполнения в этом конкретном месте.
Проблема с прерываниями состоит в том, что:
1) Приложение не может включать/выключать их, это может делать только ядро. Это непереносимо.
2) Прерывание опять же приходит в ядро, после чего ядро должно каким-то образом сообщить об этом приложению. Например, в случае линукса, если происходит деление на ноль, приложению прилетает SIGFPE, который сложно хендлить (попробуй узнай какой поток его вызвал). И тоже непереносимо между разными ОС.
В статье незря упоминалось, что иногда переполнение — это абсолютно нормально. Например, при рассчете CRC. Если бы у нас на каждую итерацию CRC/SHA1/etc прилетало прерывние, мы бы получали по два переключения контекста, что уронило бы производительность практически в ноль.
Я где-то тут читал теорию о том, что они таким образом пытаются бороться с приложением-казино для смартфонов. Дескать, запускают его и смотрят куда оно ходит. А ходит оно и на свои сервера (которые очень удобно хостить в облаках Амазона), и к Комодо за проверкой сертификатов, и к рекламщикам. Вот и блокируют всё подряд.
Да хоть в (почти )Земных условиях: Так, температура вакуума в системе отсчёта частицы, двигающейся со стандартным земным ускорением свободного падения 9,81 м/с², равна 4×10^(−20) К.. Это намного, намного меньше чем температура реликтового излучения, например.
И почему зависимость от формы тела?
При равноускоренном движении позади ускоряющегося тела тоже возникает горизонт событий, но разница в граничных условиях задач даёт различные решения для этих эффектов. В частности, подход, основанный на расчёте ограниченных интегралов по путям, даёт следующую картину для эффекта Унру: «тепловая атмосфера» ускоренного наблюдателя состоит из виртуальных частиц, но если такая виртуальная частица поглощается ускоренным наблюдателем, то соответствующая античастица становится реальной и доступна для детектирования инерциальным наблюдателем. В этом случае ускоренный наблюдатель теряет часть своей энергии.
Я думаю, вы не будете спорить с тем, что вероятность поглощения виртуальной частицы прямопропорциональна сечению предмета в плоскости перпендикулярной вектору ускорения.
Идея Маккаллоха в том, что инерция возникает в следствие излучения Унру, эффекта предсказанного общей теорией относительности. Он заключается в том, что ускоряющийся объект излучает как чёрное тело. Другими словами, вселенная нагревается, когда вы ускоряетесь.
Что-то я не понимаю. Эффект Унру очень слабый, если верить Википедии. Каким образом он может отвечать за инерцию, которая очень легко ощущается на бытовом уровне? Опять же, если инерция связана с излучением, то инерция тела будет зависить не только от его массы, но и от его формы (инерция плоского листа должна быть больше чем у шара равной масы), чего вроде раньше не наблюдалось.
Мне кажется, что автор статьи чего-то сильно не понял, либо Маккаллох гонит.
Ну да, производитель решил сэкономить и выпустил модель без термовыключателя. Вы тоже решили сэкономить и купили её.
Я конечно не агитирую покупать бытовую технику исключительно производства Miele, но есть же относительно недорогие и надежные девайсы от тех же Bosch или Siemens.
Потому что надежное термореле дорогое? А дешевое сожжет дом и производетилю придется покрывать ущерб? Уж лучше дешевый но надежный термопредохранитель.
А почему бы не написать всё же сразу на Swift? Нужно будет всего лишь использовать правильный linker script который положит нужные данные в нужные секции. Зато никаких трамплинов на C.
Квантовые компьютеры теоретически могут нанести вред криптографии с открытым ключом. В блокчейнах ничего сложнее хешей не используется, поэтому им будет более-менее пофиг.
Внутренний контроллер нужен для защиты банки от неправильного использования: переразряд, перезаряд, превышение допустимого тока. Так же контроллер не даст заряжать банку если напряжение на ней опустилось ниже критического минимума, потому что это сильно повышает вероятность взрыва банки.
Плюс, у защищенной банки есть механическая защита от перегрева/превышения тока: при сильном нагреве разрушается плюсовой контакт.
Эти все дополнительные меры безопасности на случай, если с внешним контроллером что-то произойдет, либо банка будет использоваться без контроллера (ну например в светодиодном фонаре, не все они имеют защиту от переразряда).
Вообще, надо заметить что все потребительские устройства разрабатываются с рассчетом на использование батарей со встроенным контроллером (если используются сменные 18650 батареи, естественно), поэтому защит там может и не быть вовсе.
Банки без внутреннего контроллера можно использовать в своих устройствах, при условии что эти батареи будут несменными и вы точно понимаете что делаете. Лично, я бы не стал пользоваться такими банками.
А если мы пишем на чем-то типа С, то у нас есть целая куча либо быстрых, либо переносимых способов.
Но всё равно, сигнал либо придет асинхронно и тогда попробуй обработай его правильно. Исключение то нельзя бросить из обработчика. Только хардкор, только longjmp что подходит только для C и то с большими оговорками.
А если обратывать сигнал синхронно, то проще уж проверять делитель или флаговый регистр, так хоть переключений контекста не будет.
Это кажется довольно логичным, потому что процессор не должен заниматься валидацией обрабатываеммых данных. А исключение при делении на 0 — это рудимент эпохи программируемых калькуляторов.
Проблема с прерываниями состоит в том, что:
1) Приложение не может включать/выключать их, это может делать только ядро. Это непереносимо.
2) Прерывание опять же приходит в ядро, после чего ядро должно каким-то образом сообщить об этом приложению. Например, в случае линукса, если происходит деление на ноль, приложению прилетает SIGFPE, который сложно хендлить (попробуй узнай какой поток его вызвал). И тоже непереносимо между разными ОС.
В статье незря упоминалось, что иногда переполнение — это абсолютно нормально. Например, при рассчете CRC. Если бы у нас на каждую итерацию CRC/SHA1/etc прилетало прерывние, мы бы получали по два переключения контекста, что уронило бы производительность практически в ноль.
Да хоть в (почти )Земных условиях: Так, температура вакуума в системе отсчёта частицы, двигающейся со стандартным земным ускорением свободного падения 9,81 м/с², равна 4×10^(−20) К.. Это намного, намного меньше чем температура реликтового излучения, например.
При равноускоренном движении позади ускоряющегося тела тоже возникает горизонт событий, но разница в граничных условиях задач даёт различные решения для этих эффектов. В частности, подход, основанный на расчёте ограниченных интегралов по путям, даёт следующую картину для эффекта Унру: «тепловая атмосфера» ускоренного наблюдателя состоит из виртуальных частиц, но если такая виртуальная частица поглощается ускоренным наблюдателем, то соответствующая античастица становится реальной и доступна для детектирования инерциальным наблюдателем. В этом случае ускоренный наблюдатель теряет часть своей энергии.
Я думаю, вы не будете спорить с тем, что вероятность поглощения виртуальной частицы прямопропорциональна сечению предмета в плоскости перпендикулярной вектору ускорения.
Что-то я не понимаю. Эффект Унру очень слабый, если верить Википедии. Каким образом он может отвечать за инерцию, которая очень легко ощущается на бытовом уровне? Опять же, если инерция связана с излучением, то инерция тела будет зависить не только от его массы, но и от его формы (инерция плоского листа должна быть больше чем у шара равной масы), чего вроде раньше не наблюдалось.
Мне кажется, что автор статьи чего-то сильно не понял, либо Маккаллох гонит.
Я конечно не агитирую покупать бытовую технику исключительно производства Miele, но есть же относительно недорогие и надежные девайсы от тех же Bosch или Siemens.
Плюс, у защищенной банки есть механическая защита от перегрева/превышения тока: при сильном нагреве разрушается плюсовой контакт.
Эти все дополнительные меры безопасности на случай, если с внешним контроллером что-то произойдет, либо банка будет использоваться без контроллера (ну например в светодиодном фонаре, не все они имеют защиту от переразряда).
Вообще, надо заметить что все потребительские устройства разрабатываются с рассчетом на использование батарей со встроенным контроллером (если используются сменные 18650 батареи, естественно), поэтому защит там может и не быть вовсе.
Банки без внутреннего контроллера можно использовать в своих устройствах, при условии что эти батареи будут несменными и вы точно понимаете что делаете. Лично, я бы не стал пользоваться такими банками.