sbcl-win32-1.0.40 альфа-версия

[dmitry_vk]

Выложил для тестирования бинарную сборку SBCL с нитями в https://sites.google.com/site/dmitryvksite/sbcl-distr/sbcl-1.0.40-threads-2.msi. Если есть возможность прогнать тесты (два основных теста, которые я использовал при отладке я выложил в http://gist.github.com/582848) и отписаться о результатах, было бы здорово.

Comments

[dmitry-vk.livejournal.com]

У меня к вам вопрос — я сейчас пытаюсь запустить hunchentoot, а он не принимает соединения (то есть, соединения принимаются, но до обработки запроса дело не доходит — внутри hunchentoot::accept-connections не возвращается вызов wait-for-input). Не могли бы вы посмотреть, а то я не очень хорошо разбираюсь в виндовом IO?

[akovalenko.livejournal.com]

Я пока не воспроизвёл -- всё работает [увы! в кои-то веки..], hunchentoot принимает соединения и отвечает.

Давайте попробуем изолировать проблему в USOCKET.

(usocket:with-socket-listener (sv "0.0.0.0" 8024)
           (usocket:wait-for-input sv :ready-only t :timeout 3600)
           (usocket:socket-accept sv))

Этот код должен висеть в ожидании, а при подключении [напр. telnet localhost 8024] сразу вернуть работающий stream. Пожалуйста, расскажите, как у вас.

(Кстати, следите за тем, чтобы использовать незанятый порт -- а то с обработкой ошибок winsock в sbcl бывает невесело).

[akovalenko.livejournal.com]

Забыл про одну подробность: в вашей последней бинарной сборке CONTRIBS не вошли в инсталляционный пакет (наверное, они просто не построились). Так вот, если вы тестируете её же, поставили собранный инсталлятор стандартным способом (или просто имеете непустой SBCL_HOME) -- у вас могут грузиться FASLs от предыдущего sbcl-1-0-40 (который у вас стоял, или который собирали...). Я, правда, ещё не видел, чтобы это не приводило очень быстро к сваливанию в LDB -- но если у вас предыдущий код близок к актуальному, псевдослучайные глюки были бы в такой ситуации вполне естественны.

В общем, я hunchentoot запускаю на своей сборке где-то недельной давности (+OVERLAPPED, но влиять в данном случае не должно). Как я вижу, после этого вы уже коммитили; если в случае с hunchentoot речь идёт специфически о регрессии последних нескольких дней, предупредите (буду тогда сначала пересобирать, а потом уже думать :)

[dmitry-vk.livejournal.com]

Они не вошли, потому что были ошибки при их сборке. Я их недавно исправил в коммите Handle EOF on reading from pipes (http://github.com/dmitryvk/sbcl-win32-threads/commit/9e5361bb7dadf5f20be8bb433c98a59748256905). Проблема была в том, что скрипты сборки контрибов передают команды SBCL'ю через пайп, а при чтении из закончившегося пайпа возвращался не "конец файла", а поднималось исключение, которое интерпретировался как ошибка сборки; сами собранные contribs при этом работали нормально.
Я не думаю, что речь идет о регрессии, но думаю, что это как-то связано с OVERLAPPED IO. Проверяю на своей последней версии (Add workaround for LoadLibrary hang in REPL (http://github.com/dmitryvk/sbcl-win32-threads/commit/64eeabc90fee571c9cb8dafaebdf0238b925b269)) из консоли и из REPL'а.

[dmitry-vk.livejournal.com]

Я попробовал последнюю вашу версию (исправив ошибку компиляции в pthreads_win32.c). Там такая же картина - зависает на unix-fast-select до завершения таймаута (я его уменьшил до 10 секунд). В файле wrap.c есть реализация select для винды, но как скрестить select с используемым OVERLAPPED IO я пока не разобрался.

[akovalenko.livejournal.com]

В том usocket, что стоит у меня (довольно свежий), wait-for-input не использует sbcl-ные потроха с unix-fast-select, делает всё сам (WSAEventSelect там у него свой и прочее). Если у вас не так, надо обновить usocket, наверное. Ну а если hunchentoot пользуется sbcl-ным wait-for-input -- значит, отличия в hunchentoot (тут я не знаю, обновить его надо или состарить :). Возможно, вы как-то по-другому конфигурировали hunchentoot -- у меня в threaded sbcl win32 он запускает отдельный тред, никаких настроек я не делал.

OVERLAPPED влиять не должен (или, если должен, то только в хорошую сторону). SBCL-ный виндовый unix-fast-select в принципе не может работать, когда ждать приходится на несокетах и сокетах разом. Я не очень понимаю устройство SBCL около sub-serve-event, with-fd-handlers и их друзей, но если ханчентут использует эту часть SBCL для мультиплексирования REPL и обработки сокетов -- проблемы гарантированы.

Реализация wait-for-input, которую я сейчас вижу в USOCKET, сделана правильно (WSAEventSelect -- внимание, для акцептов там отдельный флаг -- и ожидание на event'е). В перспективе в SBCL надо бы сделать аналогично, чтобы event loop с fd-handlers можно было бы пользоваться под виндой.

[dmitry-vk.livejournal.com]

Спасибо, обновление usocket из svn помогло, хотя и не полностью.

[akovalenko.livejournal.com]

P.S. Думаю, что попытка выполнить винсочный select() на консоли, на которой есть outstanding read, может виснуть на том же GetFileType (или каком-либо его низкоуровневом аналоге). В общем, текущий sbcl-ный вызов unix-fast-select из serve-event.lisp при установленном fd-handler'е на консоли -- ничего хорошего не принесёт; если можно отучить его виснуть, он будет возвращать ошибку.