SBCL-1.0.42

[dmitry_vk]

Собрал виндовый инсталлятор SBCL 1.0.42 (раньше использовал 1.0.40) с поддержкой нитей.

https://sites.google.com/site/dmitryvksite/sbcl-distr/sbcl-1.0.42-threads.msi

Comments

[basp.livejournal.com]

А насколько это рабочая версия? Кажется, вы писали, что не все тесты на gtk-биндинг срабатывают?
И скажите, пожалуйста, какие перспективы того, что ваш форк войдет в официальную ветку sbcl?

[dmitry-vk.livejournal.com]

В целом, версия рабочая, нити должны работать. У Gtk+ проблемы связаны не с нитями, а с вводом-выводом.
Перспективы по вливанию кода, я думаю, вполне хорошие — я собираюсь этим заняться после выхода 1.0.43 (должна выйти в ближайшие дни).

[love5an.livejournal.com]

очень круто, все-таки
огромное спасибо!

[akovalenko.livejournal.com]

1. `thread-this' потерялся куда-то (я не про бинарный билд, а про исходники, как всегда :) ). Пока обхожусь (sap-int (%thread-sap)), вроде то же самое по смыслу?..
2. Рабочий interruptible sleep у меня есть [локально], сейчас буду прикручивать на место штатного SleepEx.
3. Правильно ли я понимаю, что alien routine names вида "Blablabla@" единственным преимуществом имеют статическую линковку? [т.е. с @ православно, но работать будет всё равно].

[akovalenko.livejournal.com]

3. ...имею в виду Blabla@<argsize>, конечно [сожралось форматирование]

[dmitry-vk.livejournal.com]

1. Поздно заметил. Да, результат должен быть одинаковым.
3. Как я понимаю, в "холодной" фазе сборки просматривается не все внешние символы. Я не разбирался с этим, но в win32-os.c есть функция scratch (нигде не вызываемая), в которой вызываются с нулевыми параметрами все функции, используемые рантаймом.

[(Anonymous)]

В тесте с точками та же картина -- сначала всё отлично, потом точки выводиться перестают и 100% загрузка одного из четырёх ядер.

Q9600, Win7.

laser123

[akovalenko.livejournal.com]

О, вы уже 1.43 мержите, классно.
А откуда взялась идея, что gcc4 не умеет -mno-cygwin? Боюсь, что это особенность билда/ветки, а не версии: у меня mingw gcc 4.6, и он прекрасно умеет (пришлось сделать его доступным как gcc-3, чтобы меньше мучиться с sbcl :)

[dmitry-vk.livejournal.com]

При запуске gcc -mno-cygwin из-под cygwin он ругается, что не умеет. Мне как-то казалось, что cygwin использует обычный mingw. Буду знать.
Да, надо сразу мержиться как можно раньше, чтобы проблем потом не поиметь. Я уже готовлю серию патчей - сперва всякое разное (инсталлятор, мелкие баги), затем - нити, и затем - IO.

у меня тоже нет thread-this

[avodonosov.blogspot.com (from livejournal.com)]

> `thread-this' потерялся куда-то (я не про бинарный билд, а про исходники, как всегда :) ).

Не понял насчет "не про бинарный код, про исходники".

Но у меня тоже нет thread-this.

0: ("bogus stack frame")
1: (SB-THREAD:INTERRUPT-THREAD #<SB-THREAD:THREAD "hunchentoot-listener-1" RUNNING {24C76269}> QUIT)
2: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-RECURSIVE-LOCK]324))
3: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK ..)
4: (HUNCHENTOOT:STOP-SERVER #>HUNCHENTOOT::SERVER {24C75D11}<)

Это я пробую предлагаемый бинарник.

Re: у меня тоже нет thread-this

[akovalenko.livejournal.com]

Переопределите interrupt-lisp-thread, как вот в этом коммите:
http://github.com/akovalenko/sbcl-win32-threads/commit/0aff5eb82bf7a8bcd721bb2e7fab378b6355c4ec
Больше нигде thread-this не используется. («Про исходники» — это было к тому, что бинарь я не проверял, поскольку у меня были локальные изменения, которые всё равно мержить и пересобирать).

Сейчас у dmitry-vk в git исходники уже слиты с 1.0.43, там проблемы thread-this нет :)

Про :append, кажется, понимаю, в чём дело.

[avodonosov.blogspot.com (from livejournal.com)]

Есть еще какой-то вроде баг в IO.

(with-open-file (f "/tmp/log.txt"
:direction :output
:if-exists :append
:if-does-not-exist :create)
(format f "test message: ~A~%" "hello"))

Эта форма почему-то не добавляет текст к файлу, а просто переписывает файл. Т.е. несмотря на :if-exists :append, работает как будто :if-exists :overwrite.

А вообще, это классно иметь многопоточный SBCL. Я это сейчас случайно прочувствовал.

Проверить кое-что нужно было. Я slime запустил, даже не помнил какой у меня лисп выбран для slime.

Заметил, что после запуска hunchentoot, slime не висит. Сразу не понял, что к чему (я не помнил что у меня многопоточная версия). Сижу, как белый человек дальше работаю, и в бэкграунде мысль: "странно, как это получается..., вроде висеть должно".

[akovalenko.livejournal.com]

Пофиксил append в своей ветке:
http://github.com/akovalenko/sbcl-win32-threads/commit/76312ab3b6a6db68e21553da0b5fbeb01a3d43ec

[akovalenko.livejournal.com]

P.S. На всякий случай выкладываю свой бинарник (это "HEAD" от dmitry-vk плюс фикс :append и некоторые несущественные мелочи).
http://sw4me.com/private/sbcl-1.0.43.13.msi

[avodonosov.blogspot.com (from livejournal.com)]

Есть еще одна проблема с IO.

Когда я запускаю hunchentoot 1.1.0, и пытаюсь открыть браузером страницу на нем, браузер висит в состоянии "wait for localhost..." (но _не_ отваливается с ошибкой).

Т.е. он соединяется с серверным сокетом, но сервер ничего не пишет в ответ. Судя по всему, sb-unix:select не видит, что к сервеному сокету клиент приконектился (см. backtrace ниже).

Вопрос: это баг? Или know issue, которое и не должно работать? Связанно ли это с http://thread.gmane.org/gmane.lisp.steel-bank.devel/15040/focus=15303?

Backtrace потока "Hunchentoot listener (*:4242)"

...
17: ("foreign function: #x40F8BF")
18: ((FLET SB-UNIX::SELECT) #.(SB-SYS:INT-SAP #X0396FF74))
19: (USOCKET::WAIT-FOR-INPUT-INTERNAL #S(USOCKET::WAIT-LIST :%WAIT (#<SB-BSD-SOCKETS:INET-SOCKET 0.0.0.0:4242, fd: 6 {2527A989}>) :WAITERS (#) :MAP #<HASH-TABLE :TEST EQL :COUNT 1 {25055451}>))[:EXTERNAL]
20: (USOCKET:WAIT-FOR-INPUT #S(USOCKET::WAIT-LIST :%WAIT (#<SB-BSD-SOCKETS:INET-SOCKET 0.0.0.0:4242, fd: 6 {2527A989}>) :WAITERS (#) :MAP #<HASH-TABLE :TEST EQL :COUNT 1 {25055451}>))[:EXTERNAL]
21: (USOCKET:WAIT-FOR-INPUT #<USOCKET:STREAM-SERVER-USOCKET {23DB6D09}>)[:EXTERNAL]
22: ((SB-PCL::FAST-METHOD HUNCHENTOOT:ACCEPT-CONNECTIONS (HUNCHENTOOT:ACCEPTOR)) #<unavailable argument> #<unavailable argument> #<HUNCHENTOOT:ACCEPTOR (host *, port 4242)>)
23: ((FLET #:WITHOUT-INTERRUPTS-BODY-[BLOCK365]370))
24: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
25: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]300))
26: (SB-THREAD::CALL-WITH-MUTEX ..)
27: (SB-THREAD::INITIAL-THREAD-FUNCTION)
28: ("foreign function: #x419DB7")
...

[akovalenko.livejournal.com]

А вы пробовали обновить USOCKET из SVN? (Дмитрию это вроде бы помогло).
Современный USOCKET не должен попадать в SB-UNIX::SELECT, так что у меня есть основания для этой рекомендации.

[akovalenko.livejournal.com]

P.S. Почитал указанный диалог. Он относится к коду, которого уже нет [вместо него overlapped I/O], ну и, кроме того, проблемы акцепта сокетов не имеют отношения ни к старому, ни к новому коду в обсуждаемом месте.

[Хех, повод порадоваться, что наше текущее win-fu покрывает не только сокеты, но и консольный I/O :) теперь меньше поводов не принимать его в upstream].

[akovalenko.livejournal.com]

P.P.S. А, вру, код-то есть. Но к select() и accept() он всё равно никаким боком не относится.

[akovalenko.livejournal.com]

[Рассматривая github]
Если влить фикс для :append вам мешает прилипший к нему недо-mmap() — не стесняйтесь критиковать. Git пока только осваиваю, так что такие проколы бывают.

[dmitry-vk.livejournal.com]

Я на самом деле просто забыл об этом :( Спасибо, что напомнили.

[akovalenko.livejournal.com]

Ситуацию с прерываниями я сейчас, возможно, наполовину понимаю.
1. В gencgc.c, там где сохраняются win32_data.interrupts в preserve_pointers(), они сохраняются только для других тредов, но не для того, который это делает. Идея могла быть такой, что раз уж этот тред дотуда дошел, значит, прерывания разрешены и check_pending_interrupts их уже почистил. Но как минимум в современном коде, где сигналы на GC и на "всё остальное" могут блокироваться по отдельности, это неверно. В without-interrupts может пройти куча времени до реакции на SIGHUP/interrupt_thread, а за это время gc запросто перетащит функцию в другое место.

2. Описанное выше стало в итоге ясно потому, что я сначала обнаружил более простую штуку, из-за которой прерывания перестают работать: в маске сигналов отключаются все deferrable, остается один gc. Кто-то их блокирует и не убирает за собой (причем не в лиспе, похоже: с unwind-protect особо страшного не натворить). В общем, когда я нажимал C-c C-c по несколько раз, а потом давал sb-unix::unblock-deferrable-signals вручную -- часть обработчиков выводила в отладчик нормальный "interrupt из emacsа", а другая часть -- в основном давала ACCESS_VIOLATION, финишируя в handle-win32-exception, но и глюки "полуработающего" вида тоже бывали. Вот эти эффекты совсем пропали после того, как я добавил preserve_pointers для прерываний *самого* работающего треда.

Вот чего я не знаю -- где искать злобного выключателя сигналов (и как правильно пользоваться *unblock-deferrables-on-enabling-interrupts-p*, например, тоже не знаю).

P.S. У меня там очередная реформа с I/O: обычные файлы теперь открыты overlapped; ну и можно открывать //./COM5, //./PhysicalDrive0 и прочее похожее из device namespace. Ещё в качестве видимого полезного эффекта появилась работа с 64-битной FILE-POSITION. По I/O все закоммичено-выложено, а вот с сигналами и GC пока экспериментирую.

P.P.S. Заодно про hunchentoot+usocket+sbcl кое-что выяснилось: знаю, почему сокетные хэндлы утекают, как не в себя, и где править. Но это ещё в порядок не приведено.

[dmitry-vk.livejournal.com]

То, что сборщику не отдаются interrupts от текущей нити - это однозначно недоработка. С вашим решением я полностю согласен.

С *unblock-deferrables-on-enabling-interrupts-p* я сам еще окончательно не разобрался. Выключателя сигналов можно искать, логируя стек в момент выключения сигналов.

А что за проблема с текущими хэндлами сокетов? Я с ней, вроде бы, не сталкивался.

Спецом зарегался....

[realxset.livejournal.com]

выразить благодарность, и уважение не перевелись еще ТАКИЕ люди! Юзаем SBCL для риалтаймового сервера MMORG. Под Винду хотелось бы иметь полноценную версию SBCL с потоками, а тут Вы такое дело провернули. В общем надеемся и уповаем.

Re: Спецом зарегался....

[dmitry-vk.livejournal.com]

Спасибо! Рад слышать, что SBCL используется в реальных проектах.
PS. Для комментирования в lj не обязательно регистрироваться - можно комментировать анонимно или воспользоваться OpenID.

[fedotawa.livejournal.com]

Weblocks (с usocket из SVN) вылетает при попытке соединения. Может быть, это проблема самого Weblocks/Hunchentoot, но вот бэктрейс: http://paste.lisp.org/display/115692

[dmitry-vk.livejournal.com]

Это проблема в usocket. Я им написал, но мне пока не ответили.
http://common-lisp.net/pipermail/usocket-devel/2010-September/000625.html

[akovalenko.livejournal.com]

[Был уверен, что отправил вам коммент по этому поводу, но что-то не вижу...]

Обнаружилась интересная штука в native API (keywords: NtSetInformationFile / FileModeInformation / FILE_SYNCHRONOUS_IO_ALERT), которая позволяет на синхронном файловом хэндле включить прерывания ввода-вывода через QueueUserAPC (принципиальная новость в том, что так можно рубить ввод/вывод на анонимных пайпах и на унаследованных дескрипторах -- там, где overlapped не бывает). Также обнаружилось, что когда мы висим на синхронном recv() на overlapped-сокете, поставленные в очередь APC тут же вызываются (хотя сама операция и не прерывается в этом случае с ERROR_OPERATION_ABORTED, в отличие от обычного ReadFile; подозреваю, что ее можно срубить "устаревшим" WSACancelBlockingCall() изнутри APC, и совершенно точно из нее можно выпрыгнуть нелокальным переходом, но последнее стрёмно — хоть на поверхностный взгляд ничего и не ломается).

Сам API исторически довольно стабилен (не менялся с Winnt4sp6 до Win7). В итоге APC все-таки оказываются неплохим приближением для сигналов.

P.S.: Не знаете ли, define-alien-callback умеет соглашение stdcall? (и если да, то как?) В "наружных" вызовах SBCL замечательно решает проблему stdcall/cdecl, не требуя явного указания протокола -- но увы, в callback'ах это имеет значение.

[dmitry-vk.livejournal.com]

Я ко всяким недокументированным API отношусь с опаской, потому что в Win32 они уже менялись. Хотя если ничего другого нет, то ими следует воспользоваться.
APC не заменяют сигналы по той причне, что для их прихода нить должна совершать определенные действия. замена сигналов - это Kernel APC, которые срабатывают сразу, но Kernel APC можно вызвать лишь из кода драйверов; на codeproject.com даже есть библиотечка QueueUserAPCEx, которая предоставляет аналог сигналов (нить может быть прервана в любом месте), но она требует установки своего драйвера в систему.

Про поддержку stdcall я не знаю. Alastair Bridgewater выкладывал поддержку stdcall-коллбэков (http://www.lisphacker.com/blog/display/some-sbclwin32-hacking), и его код отличается от того что сейчас в sbcl (в его коде у функций/макросов есть параметры для указания call convention, которых нет в текущем sbcl).