SBCL - как вывести состояние процессов

Я конечно поразмыслю как теоретик, но как всякая обычная программа в линуксе, когда она ожидает ввода, то она говорит «Введите ...». В LW наверно добавлены к какие-то свисто-пердящие инструкции для функций ввода, немудрено что подобное надо делать для sbcl самим.

Наверно линукс может показать список процессов находящихся в таком состоянии, но наверно это грязноватый хак.

Ай, чёрт! Не так понял вопрос. Ладно - не буду удалять. Скажу, что подобных функций в sbcl не встречал.

Вижу только всякие SB-THREAD::thread-waiting-for и различные слоты в инспекторе.

Я думаю, что это должен быть встроен код для всех функций, переводящих тред в состояние ожидания. На входе в функцию нужно править текст состояния потока, а на выходе - ставить в running.

Соответственно и в обработчиках сигналов тоже можно что-то писать.

Хотя может sb-thread::thread-waiting-for тоже поможет.

Ладно, посмотрю исходник sbcl самостоятельно, если руки дойдут, и отпишу тогда (если не забуду).

Это фича ОС-зависимая, и в принципе делается через FFI. На винде можно использовать tool help library https://msdn.microsoft.com/en-us/library/windows/desktop/ms686728(v=vs.85).aspx и потом системные функции типа NtQueryInformationThread

Спасибо, идея ясна. Скачал process explorer, прочитав это. Там он показывает стек каждого треда, жаль, что неясно, как сопоставить номера из process exlorer и из sbcl. А как я хочу - так не делается?

В SBCL такой функциональности из коробки нет, но сделать можно.

Тред SBCL это структура. В ней есть поле os-thread.

(defvar *os-thread* (sb-thread::thread-os-thread *thread*))

typedef struct pthread_thread {
  pthread_fn start_routine;
  void* arg;
  HANDLE handle;
...
}

(defun get-thread-handle (thread)
  "Retrieves WIN32 thread HANDLE from SBCL thread"
  (declare (type sb-thread:thread thread))
  (let* ((pthread-pointer
           (sb-sys:int-sap (sb-thread::thread-os-thread thread)))
         (pthread-alien
           (sb-alien:sap-alien
            pthread-pointer (sb-alien:struct nil
                                             (start-addr (* t))
                                             (arg (* t))
                                             (handle (* t))))))
    (sb-alien:alien-sap (sb-alien:slot pthread-alien 'handle))))

В частности, взять id виндового треда:

(defun get-thread-id (thread)
  "Retrieves WIN32 thread ID from SBCL thread"
  (declare (type sb-thread:thread thread))
  (sb-alien:alien-funcall
   (sb-alien:extern-alien "GetThreadId" (function sb-alien:unsigned
                                                  (* t)))
   (get-thread-handle thread)))

Спасибо! Я наблюдал внезапное крушение потока читателя SWANK в моём приложении. Печально то, что многие ошибки имеют плавающий характер.

Вчера эта ошибка была, сегодня её уже нет. Может быть, дело в том, что я починил utf-8. Но по utf-8 SWANK корректно валился. А тут просто тред чтения исчезает в какой-то момент.

Если эта ситуация повторится или если что-то ещё будет зависать - попробую по мотивам твоих цитат напилить что-нибудь.

Печально то, что многие ошибки имеют плавающий характер

На самом деле, многие проблемы лежат в том, что SBCL на винде использует эмуляцию POSIX вместо работы с нативным Win32 API, в частности, всякие там read/write из stdio вместо ReadFile/CreateFile/WriteFile ну и тыпонел. Вобщем, этот слой эмуляции, использующий номера FD итд - он крайне ненадежен и вообще, кривой, и поэтому, его лучше, использовать не надо. Антон Коваленко, про которого я раньше много говорил, однажды это все починил, переведя на Win32 API, но полностью его патчи не приняли, только частично(в основном потому что мейнтейнеры SBCL имеют как бы это помягче, слишком unix-like mind), что вобщем-то жалко, но ты можешь сконтачиться с ним и с мейнтейнерами и попробовать протолкнуть некоторые полезные фичи. Я лично в свое время помог им перестать сегфолтиться при вызове COM-интерфейсов итд, ну вобщем, рекомендую попробовать все же все это починить - у меня лично щас времени не слишком много, а так бы взялся - если что - спрашивай советов.

А чем плох POSIx? Я понимаю, что там кривая реализация, но а если её починить?

POSIX ничем не плох. Плохо то что SBCL-мейнтейнеры пытаются POSIX под видной реализовать, что вобщто, достаточно сложно

Стратегия ясна. Вопрос только, готов ли я к такой великой миссии. Подождём, посмотрим, как дальше будет работать. Пока у меня хватает дел по кросс-плафторменным багам в редакторе.