а что было?

ща регулярку скину

Если регулярки составлены не верно, т.е. без exclude то поведение ожидаемое

пповерю

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

это брак

так никто не делает, потому что совершенно не поддерживаемое получается, и будет выстреливать в ноги в будущем

давай лучше эти же усилия вложим в более управляемую архитектуру? ну круто же будет, не иметь 100500 затычек, а знать что не протечет, скажем так. by design

относительно задержек на релоад конфига - это действительно не важно irl, пока не импактит датаплейн.
в случае accel-ppp из плохого может случиться - так только что какая-то сессия создастся со все еще старыми настройками, все остальное работает в ядре.
или клиент не получит ответ на retryable connection attempt

Если будете релоад чинить, то реально ли сделать изменения всего конфига доступным через релоад?

+++

не в первую очередь. сначала нужно починить существующее, фичи - после

многие вещи удобно было бы менять через cli

и лучше case-by-case, не любой релоад применим в рантайме для существующих сессий

тот же loglevel, или вланы слушаемые для ipoe

loglevel кажется и так меняется, нет?

нет, только для модулей verbose 0/1

ок. в ближайших планах такого пока нет

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

зачем? модуль вообще не должно волновать. ему дали - он взял