Я, честно говоря, потерял дар речи и немного шокирован. Нет ли

здесь программистов на Perl?
Не пользователи pm, настоящие программисты на Perl?
Я имею в виду людей, которые знают BEGIN и END?

...
my $f = $0; $fe =~s/.pl$//; file_out("$f.pid",$$);
BEGIN { "read save data\n" }
END {
"write save data\n";
print "Going down ... \n";
$f = $0; $fe =~s/.pl$//;
if (-e "$f.restart" && `cat $f.restart` == 1 ){ print "reboot \n"; exec("perl $0"); } else { print "no reboot\n";}
}

А что непонятно с BEGIN/END?

Почему здесь никто этим не пользуется?

Когда нужно - пользуются. Например, он используется в use под капотом. Но в целом, они редко нужны.

Стикер

Ясно. Синглетонами, ещё, поди балуешься )

., и без systemd....

Я пользуюсь BEGIN периодически. END не припомню, чтобы использовал

END { disconnect_database();}

Он и так должен отсоединиться, когда объект будет уничтожаться

за тебя ОС отключит соединение, когда процесс прибъётся

И что показывает база данных? Я никогда не слышал, чтобы операционная система знала учетные данные для входа, входила в базу данных и говорила: "Простите, любезнейший, процесс мертв".

троллейбус-из-буханки.жпг

Когда процесс закрывается ОС закрывает все его дескрипторы. В том числе и сетевые сокеты. Во время закрытия сетевого сокета для TCP идет спец пакет "сокет закрыт с другой стороны". По нему на стороне сервера ОС информирует СУБД что дескриптор закрыт и уже СУБД сама делает что ей надо в связи с отключением коннекта.

да видимо он хочет что-то типа END{ $dbh->exec("INSERT INTO DEAD_PROCESSES ($$)"; . Я только не пойму зачем...

Чистить за собой ресурсы - вполне правильная концепция. Впрочем мнений может быть много, художника обидеть каждый может ))

Еще один... Чистить ресурсы при порванном коннекте должен сервер. Если он не чистит - его проблемы.

совершенно верно. И для этого "нормальный" инструмент типа деструктора.

Почему порванном? Вполне себе живом, просто за ненадобностью надо почистить, и не надеяться, что само все рассосется.

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

Верно, соединение живое еще. И скрипт должен освободить ресурсы, которые занимал, не надеясь, что ОС сама что-то за него сделает.

Это антипаттерн.

Наоборот - правильный подход. А судьи кто?

Здравый смысл. Деструктор - дорого.

А уж в каком месте это делать - вопрос другой.

Не надо говорить ОС - забери ресурсы во время завершения работы программы. Это глупость.

Совсем не глупость, а разумный профессиональный подход. Если стоит задача острого тюнинга - то есть какой-то смысл так не делать, в других случаях - делать обязательно.

бд была примером и надо сказать не самым удачным. а вот файлы за собой прибрать -- это уже вполне реальная тема. не всегда можно файлы сразу удалять

Не я придумал использовать ее в качестве примера. Временный фаил - удачный пример виртуального ресурса (то есть то что фаил временный ОС не знает, правда) и это, кстати, интересно, потому что я-бы, наверно, хотел какую-нибудь временную папку для каждого процесса на уровне ОС (инициализирующуюся по просьбе, конечно).

другой вариант, когда сервис, сообщивший о своём завершении, ускоряет процесс понимания сервером, что сервис на том конце сдох. например, зависший вебсокет может 30 секунд ждать понга. ну или там паблишер-подписчик, что нет прямого контакта

О! И еще один человек, который не знает как работает TCP. Ответ на это был дан выше.

человек знает. но бывает не только коннекты в пределах одного компьютера

И TCP/IP работает там точно так-же как и в пределах одного компьютера

магически, ага. ни разу не видел коннектов зависших?

Представьте себе - обычно зависшие коннекты говорят о том что жопа в сети. А если у вас жопа в сети между сервером и СУБД, то это уже другой вопрос.

mktemp() же и так придуман, и не только он

так он не почистит за собой если приложение крашнется

для этого много десятилетий файл удаляют сразу после открытия - реально будет удален после закрытия

круто, а я не знал про такую штуку

на винде жил, где это не работает?

man читал плохо :)

не админил? это ж классика вопросов "а куда делось место в /var если du показывает меньше"

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

какой хэндлер? ядру пофигу, дескриптор файла общий на весь процесс

В этом случае файл можно удалить в том процессе, который будет писать. Это тоже не всегда удобно, но ещё часть проблем снимает.