Hunchentoot: упрощение отладки удалённых серверов

В hunchentoot версии 1.1 для управления отладочным режимом используется глобальная переменная *catch-errors-p*: если она установлена в значение, отличное от NIL, то hunchentoot перехватывает все conditions, в обратном случае следует вызов invoke-debugger и разработчик получает возможность разобраться в причинах ошибки с помощью стандартного отладчика. При разработке на машине разработчика никаких проблем не возникает, наоборот, это очень удобно. Однако, при отладке на боевых удалённых серверах (порой это необходимо) эта простая схема начинает представлять угрозу. Во-первых, на серверах с реальной нагрузкой если ошибка возникает на регулярной основе может случиться так, что отладчик будет активизироваться чаще, чем вы способны на это реагировать. Во-вторых, можно забыть сбросить значение *catch-errors-p* при разрыве соединения с удалённым swank-сервером, что приведёт к тому, что потоки начнут подвисать на вызове invoke-debugger и в конце концов система просто откажется работать. Таким образом, для удобной и безопасной отладки удалённых серверов необходимо ограничивать число возможных активных вызовов invoke-debugger, а также автоматически отменять отладочный режим при отключении от удалённого процесса. Сегодня в репозиторий hunchentoot был принят мой патч, решающий описанные проблемы следующим образом:

• Постоянно поддерживается список отлаживаемых в данный момент потоков
  
• Добавлен параметр *max-debugging-threads*: максимально возможное количество одновременно отлаживаемых потоков, значение по умолчанию - 5.
• Функция debug-mode-on - активизирует отладочный режим.
• Функция debug-mode-off - отменяет отладочный режим, имеет необязательный параметр kill-debugging-threads (по-умолчанию T) , который определяет надо ли уничтожать отлаживаемые в данный момент потоки.
• В случая наличия в системе swank-сервера, в переменную swank::*connection-closed-hook* добавляется вызов debug-mode-off , который обеспечивает отмену отладочного режима и уничтожение отлаживаемых потоков после разрыва соединения.
• Описанная схема применяется только к потокам, которые созданы hunchentoot для обработки запросов.

В поддерживаемой мной git версии репозитория hunchentoot данные изменения будут через пару дней (когда попаду на работу).