Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.12.71.34] |
|
Страницы: (56) « Первая ... 47 48 [49] 50 51 ... 55 56 ( Перейти к последнему сообщению ) |
Сообщ.
#721
,
|
|
|
А завершаешь работу ты намертво грохая всю vm? Добавлено Кстати, супервизоры умеют не только супервизить и заверать дочерних супервизоров, но и динамически порождать новые процессы. В общем слишком полезная штука, что бы от нее отказываться. |
Сообщ.
#722
,
|
|
|
Цитата Астарот @ А какая разница? Если можно не позволить упасть, почему бы этого не сделать? Исключения в жизнь! Если нельзя, то нужно переподнять. Исключения нафик! Это вопрос стоимости усилий. Независимо от реализации нужно логгить и исправлять причину падения. И логгить, и исправлять нужно в обоих вариантах. Но тут вопрос, скорее, про то, что лучше, если все же упал - воскрешать или не воскрешать? |
Сообщ.
#723
,
|
|
|
Цитата Qraizer @ А какая разница? Если можно не позволить упасть, почему бы этого не сделать? Я не вижу тут противоречия. Если можно не падать - нужно не падать. А воскрешать или не воскрешать это уже если упал. Цитата Qraizer @ И логгить, и исправлять нужно в обоих вариантах. Само-собой. Просто в одном варианте ты остановишься и будешь стоять пока не исправишь, в другом - будешь как-то бежать периодически спотыкаясь. Что лучше - зависит от каждого конкретного случая. |
Сообщ.
#724
,
|
|
|
Цитата Астарот @ Зачем? Обычно звоним в датацентр и просим обесточить всю стойку А завершаешь работу ты намертво грохая всю vm? Добавлено Цитата Астарот @ Я от них не отказываюсь, кое-где они используются. Например в хттп-сервере. Кстати, супервизоры умеют не только супервизить и заверать дочерних супервизоров, но и динамически порождать новые процессы. В общем слишком полезная штука, что бы от нее отказываться. |
Сообщ.
#725
,
|
|
|
Цитата applegame @ Зачем? Обычно звоним в датацентр и просим обесточить всю стойку В следующий раз попробуйте закинуть шашку тола! Цитата applegame @ Я от них не отказываюсь, кое-где они используются. Например в хттп-сервере. Вот чего я точно никогда не пойму, так это зачем на erlang/elixir городить свой хттп-сервант |
Сообщ.
#726
,
|
|
|
Цитата Астарот @ А зачем его городить? Уже все нагорожено до нас Вот чего я точно никогда не пойму, так это зачем на erlang/elixir городить свой хттп-сервант |
Сообщ.
#727
,
|
|
|
Цитата applegame @ А зачем его городить? Уже все нагорожено до нас Так и я о том, все давно нагорожено до нас и без OTP |
Сообщ.
#728
,
|
|
|
Сообщ.
#729
,
|
|
|
Цитата applegame @ эти процессы перестали падать от слова совсем, то исчезла необходимость городить восстановление А если баг или какой другой фейл в нижележащем слое (ОС, железо, вот это всё)? |
Сообщ.
#730
,
|
|
|
Цитата Астарот @ Ну так вопрос же о сервисах 24/7, как я понимаю.А воскрешать или не воскрешать это уже если упал. Цитата Астарот @ Вообще-то в первом варианте остановится лишь тот функционал, который помер, остальные будут продолжать работать. Другое дело, что во втором варианте он-таки будет продолжать попытки взлететь. Ежели так, то я против спотыканий. При спотыканиях оно хоть как-то, но пашет, а когда не пашет, то мотивация поправить багу выше. А вообще, никто не мешает воплотить реинкарнацию и в первом варианте, как бы, тогда вообще пофик. Просто в одном варианте ты остановишься и будешь стоять пока не исправишь, в другом - будешь как-то бежать периодически спотыкаясь. |
Сообщ.
#731
,
|
|
|
Цитата Qraizer @ А кому оно нужно было? Как идеология, это прикольная тема, практически же зайцу стоп-сигнал нужнее. Про зайца не знаю, а вот для EE это мощнейщий механизм, без него вообще их строить очень сложно, если сильно надо то есть и компиляторы, для секюрити это вообще классика,как и для логов или error handling, по сути это интерапты на уровне аппликации. Если они не нужны для твоих задач, это не значит что они не нужны никому. Добавлено вызывай его явно если есть необходимость, Добавлено Цитата D_KEY @ На практике не критично, ибо легко достигается просто через абстрактные классы без реализации и полей. Ну вообщем то да, хотя зачем в большинстве языков есть и то и то? |
Сообщ.
#732
,
|
|
|
Цитата sergioK @ вызывай его явно если есть необходимость, Явный вызов GC — моветон. А зачастую, вызов какой-нибудь System.gc() (или как там в Java) вовсе не означает, что он возьмёт и запустится. Цитата sergioK @ Ну вообщем то да, хотя зачем в большинстве языков есть и то и то? Потому что в этих языках интерфейсы и абстрактные классы имеют разную семантику. С тем же успехом можно спросить, почему в большинстве языков есть for/while, а в Бейские — только goto. |
Сообщ.
#733
,
|
|
|
Цитата D_KEY @ Цитата и не безопасность кода Если ты про отсутствие виртуальной машины, то это, в тоже время и достоинство, поскольку не мешает быстродействию и контролю. Я про прямой доступ памяти, через поинтер или ссылку. Для одних целей это хорошо, для безопасности нет. Добавлено Цитата korvin @ Явный вызов GC — моветон. А зачастую, вызов какой-нибудь System.gc() (или как там в Java) вовсе не означает, что он возьмёт и запустится. Он для этого и сделан, и он 100% запуститися, я вот если твой указатель не пустой, то результата от GC не будет. А вот зачем в С++ такое, и что с ним делать Я не понимаю. class Student:private Person {}; |
Сообщ.
#734
,
|
|
|
Цитата korvin @ Помрет, предварительно пискнув в критлог. Помрет только этот процесс, остальные-то продолжат работу. А если баг или какой другой фейл в нижележащем слое (ОС, железо, вот это всё)? |
Сообщ.
#735
,
|
|
|
Цитата Qraizer @ Ежели так, то я против спотыканий. При спотыканиях оно хоть как-то, но пашет, а когда не пашет, то мотивация поправить багу выше Это если бага у тебя, а не приходит со стороны |