Исправление firkax, (текущая версия) :
Да, действительно. Ну значит надо newlog=0; в начало переставить.
Насчёт ошибки не совсем соглашусь. В некоторых случаях это как раз не просто «не критично» а как раз даже желательно - не обрабатывать дубликаты сигналов, пришедших пока ты прошлый не обработал, например, если сигнал запрашивает дамп какой-нить тяжёлой статистики. В данном случае это действительно может быть теоретической проблемой, если после ротации логов мы переоткроем файл, после чего сразу случится ещё одна ротация и отправка второго сигнала - писать мы будем в старый ротированный файл. Но на практике такого не случится по двум причинам: 1) ротация делается намного реже 2) пустые файлы не ротируются, даже если ротацию запустить вручную с интервалом в 10мс, и второй сигнал переоткроет тот же файл что создан пустым после первого.
Но да, всё-таки стоит поддерживать любые варианты ротации, в т.ч. кажущиеся неадекватными, поскольку у нас никаого контракта с ротацией, кроме отправки сигнала, нет.
Алсо, у тебя теперь при каждой записи в лог будет дёргаться мютекс, что весьма небыстро и не слишком приятно.
Очень даже быстро. Быстрее чем сисколл записи что в файл что в сокет. В большинстве случаев он удовлетворится вообще юзерспейсом кажется (хотя это надо смотреть конкретные реализации в разных ОС). Ну и вообще если у мютекса проблемы со скоростью можно другое что-то использовать, я не зря там абстрактный t_lock в начале поставил. Семафоры в фрибсд точно юзерспейсные до тех пор пока не приходится ждать.
Исправление firkax, :
Да, действительно. Ну значит надо в начало переставить.
Насчёт ошибки не совсем соглашусь. В большинстве случаев это как раз не просто «не критично» а как раз даже желательно - не обрабатывать дубликаты сигналов, пришедших пока ты прошлый не обработал. В данном случае это действительно может быть теоретической проблемой, если после ротации логов мы переоткроем файл, после чего сразу случится ещё одна ротация и отправка второго сигнала - писать мы будем в старый ротированный файл. Но на практике такого не случится по двум причинам: 1) ротация делается намного реже 2) пустые файлы не ротируются, даже если ротацию запустить вручную с интервалом в 10мс, и второй сигнал переоткроет тот же файл что создан пустым после первого.
Но да, всё-таки стоит поддерживать любые варианты ротации, в т.ч. кажущиеся неадекватными, поскольку у нас никаого контракта с ротацией, кроме отправки сигнала, нет.
Алсо, у тебя теперь при каждой записи в лог будет дёргаться мютекс, что весьма небыстро и не слишком приятно.
Очень даже быстро. Быстрее чем сисколл записи что в файл что в сокет. В большинстве случаев он удовлетворится вообще юзерспейсом кажется (хотя это надо смотреть конкретные реализации в разных ОС). Ну и вообще если у мютекса проблемы со скоростью можно другое что-то использовать, я не зря там абстрактный t_lock в начале поставил. Семафоры в фрибсд точно юзерспейсные до тех пор пока не приходится ждать.
Исправление firkax, :
Да, действительно. Ну значит надо в начало переставить.
Насчёт ошибки не совсем соглашусь. В большинстве случаев это как раз не просто «не критично» а как раз даже желательно - не обрабатывать дубликаты сигналов, пришедших пока ты прошлый не обработал. В данном случае это действительно может быть теоретической проблемой, если после ротации логов мы переоткроем файл, после чего сразу случится ещё одна ротация и отправка второго сигнала - писать мы будем в старый ротированный файл. Но на практике такого не случится по двум причинам: 1) ротация делается намного реже 2) пустые файлы не ротируются, даже если ротацию запустить вручную с интервалом в 10мс, и второй сигнал переоткроет тот же файл что создан пустым после первого.
Но да, всё-таки стоит поддерживать любые варианты ротации, в т.ч. кажущиеся неадекватными, поскольку у нас никаого контракта с ротацией, кроме отправки сигнала, нет.
Алсо, у тебя теперь при каждой записи в лог будет дёргаться мютекс, что весьма небыстро и не слишком приятно.
Очень даже быстро. Быстрее чем сисколл записи что в файл что в сокет. В большинстве случаев он удовлетворится вообще юзерспейсом кажется (хотя это надо смотреть конкретные реализации в разных ОС). Ну и вообще если у мютекса проблемы со скоростью можно другое что-то использовать, я не зря там абстрактный t_lock в начале поставил.
Исходная версия firkax, :
Да, действительно. Ну значит надо в начало переставить.
Насчёт ошибки не совсем соглашусь. В большинстве случаев это как раз не просто «не критично» а как раз даже желательно - не обрабатывать дубликаты сигналов, пришедших пока ты прошлый не обработал. В данном случае это действительно может быть теоретической проблемой, если после ротации логов мы переоткроем файл, после чего сразу случится ещё одна ротация и отправка второго сигнала - писать мы будем в старый ротированный файл. Но на практике такого не случится по двум причинам: 1) ротация делается намного реже 2) пустые файлы не ротируются, даже если ротацию запустить вручную с интервалом в 10мс, и второй сигнал переоткроет тот же файл что создан пустым после первого.
Но да, всё-таки стоит поддерживать любые варианты ротации, в т.ч. кажущиеся неадекватными, поскольку у нас никаого контракта с ротацией, кроме отправки сигнала, нет.
Алсо, у тебя теперь при каждой записи в лог будет дёргаться мютекс, что весьма небыстро и не слишком приятно.
Очень даже быстро. Быстрее чем сисколл записи что в файл что в сокет. В большинстве случаев он удовлетворится вообще юзерспейсом. Ну и вообще если у мютекса проблемы со скоростью можно другое что-то использовать, я не зря там абстрактный t_lock в начале поставил.