Сообщение Re[3]: Эрланг и все-все-все (на самом деле, не совсем) от 29.06.2015 9:20
Изменено 29.06.2015 9:24 Философ
Здравствуйте, neFormal, Вы писали:
Ф>>Что делать с оставшейся программой, у которой убили поток?
F>ПА-НИ-КО-ВАТЬ! ААА!
Правильно, рубить процесс к чертям, ибо он в неконсистентном состоянии
Ф>>Убивать нативные потоки — очень-очень плохая идея (читай классиков). Убийство managed потоков — тоже не есть здравая мысль, почти по тем же причинам.
F>но это же проблема реализации, а не идеи
Нет, сама идея убога.
Ф>>...нужно иметь возможность гарантировать, что он в процессе своего выполнения не зааффектил ничего из внешнего мира. Даже с процессами не всегда такое возможно.
F>ну да, всё верно.
F>если технология не позволяет освобождать внешние связи, то всё плохо.
Проблема не в технологии, а в том, что в общем случае ты не знаешь, что и в какое состояние нужно всё возвращать. Простой пример: нужно ли закрывать файл, открытый в другом потоке? Может быть его удалить нужно?
Ещё пример: кому должен принадлежать мютекс, после принудительного завершения потока?
Ф>>Не имеешь ли ты ввиду часом то, что имели ввиду авторы Smalltalk'а, когда говорили об "общении" между объектами? Если да, то это плохая идея.
F>да, именно, как в ST. с этой стороны эрланг можно назвать даже объектно-ориентированным языком. с известной долей условности.
F>а чем идея плоха?
Это отдельная тема — потом отвечу (если не забуду). Если вкратце, то плохо это потому, что такой подход плодит ошибки в процессе разработки, которые могли бы быть исправлены до компиляции программы.
Ф>>Что делать с оставшейся программой, у которой убили поток?
F>ПА-НИ-КО-ВАТЬ! ААА!
Правильно, рубить процесс к чертям, ибо он в неконсистентном состоянии
Ф>>Убивать нативные потоки — очень-очень плохая идея (читай классиков). Убийство managed потоков — тоже не есть здравая мысль, почти по тем же причинам.
F>но это же проблема реализации, а не идеи
Нет, сама идея убога.
Ф>>...нужно иметь возможность гарантировать, что он в процессе своего выполнения не зааффектил ничего из внешнего мира. Даже с процессами не всегда такое возможно.
F>ну да, всё верно.
F>если технология не позволяет освобождать внешние связи, то всё плохо.
Проблема не в технологии, а в том, что в общем случае ты не знаешь, что и в какое состояние нужно всё возвращать. Простой пример: нужно ли закрывать файл, открытый в другом потоке? Может быть его удалить нужно?
Ещё пример: кому должен принадлежать мютекс, после принудительного завершения потока?
Ф>>Не имеешь ли ты ввиду часом то, что имели ввиду авторы Smalltalk'а, когда говорили об "общении" между объектами? Если да, то это плохая идея.
F>да, именно, как в ST. с этой стороны эрланг можно назвать даже объектно-ориентированным языком. с известной долей условности.
F>а чем идея плоха?
Это отдельная тема — потом отвечу (если не забуду). Если вкратце, то плохо это потому, что такой подход плодит ошибки в процессе разработки, которые могли бы быть исправлены до компиляции программы.
Re[3]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
Ф>>Что делать с оставшейся программой, у которой убили поток?
F>ПА-НИ-КО-ВАТЬ! ААА!
Правильно, рубить процесс к чертям, ибо он в неконсистентном состоянии. Именно так и делают языки для нативного кода.
Ф>>Убивать нативные потоки — очень-очень плохая идея (читай классиков). Убийство managed потоков — тоже не есть здравая мысль, почти по тем же причинам.
F>но это же проблема реализации, а не идеи
Нет, сама идея убога.
Ф>>...нужно иметь возможность гарантировать, что он в процессе своего выполнения не зааффектил ничего из внешнего мира. Даже с процессами не всегда такое возможно.
F>ну да, всё верно.
F>если технология не позволяет освобождать внешние связи, то всё плохо.
Проблема не в технологии, а в том, что в общем случае ты не знаешь что и в какое состояние нужно всё возвращать. Простой пример: нужно ли закрывать файл, открытый в другом потоке? Может быть его удалить нужно?
Ещё пример: кому должен принадлежать мютекс, после принудительного завершения потока?
Ф>>Не имеешь ли ты ввиду часом то, что имели ввиду авторы Smalltalk'а, когда говорили об "общении" между объектами? Если да, то это плохая идея.
F>да, именно, как в ST. с этой стороны эрланг можно назвать даже объектно-ориентированным языком. с известной долей условности.
F>а чем идея плоха?
Это отдельная тема — потом отвечу (если не забуду). Если вкратце, то плохо это потому, что такой подход плодит ошибки в процессе разработки, которые могли бы быть исправлены до компиляции программы.
Ф>>Что делать с оставшейся программой, у которой убили поток?
F>ПА-НИ-КО-ВАТЬ! ААА!
Правильно, рубить процесс к чертям, ибо он в неконсистентном состоянии. Именно так и делают языки для нативного кода.
Ф>>Убивать нативные потоки — очень-очень плохая идея (читай классиков). Убийство managed потоков — тоже не есть здравая мысль, почти по тем же причинам.
F>но это же проблема реализации, а не идеи
Нет, сама идея убога.
Ф>>...нужно иметь возможность гарантировать, что он в процессе своего выполнения не зааффектил ничего из внешнего мира. Даже с процессами не всегда такое возможно.
F>ну да, всё верно.
F>если технология не позволяет освобождать внешние связи, то всё плохо.
Проблема не в технологии, а в том, что в общем случае ты не знаешь что и в какое состояние нужно всё возвращать. Простой пример: нужно ли закрывать файл, открытый в другом потоке? Может быть его удалить нужно?
Ещё пример: кому должен принадлежать мютекс, после принудительного завершения потока?
Ф>>Не имеешь ли ты ввиду часом то, что имели ввиду авторы Smalltalk'а, когда говорили об "общении" между объектами? Если да, то это плохая идея.
F>да, именно, как в ST. с этой стороны эрланг можно назвать даже объектно-ориентированным языком. с известной долей условности.
F>а чем идея плоха?
Это отдельная тема — потом отвечу (если не забуду). Если вкратце, то плохо это потому, что такой подход плодит ошибки в процессе разработки, которые могли бы быть исправлены до компиляции программы.