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>, конечно [сожралось форматирование]

[akovalenko.livejournal.com]

1. Залил прерываемую реализацию sleep к себе.
2. Вопрос с линковкой снят - убедился, что в холодном ядре ещё динамической линковки нет.

[dmitry-vk.livejournal.com]

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

[akovalenko.livejournal.com]

[На всякий случай]:

В холодной фазе SBCL знает те символы, что попали в вывод nm. А вот в вывод nm они попадают так: вызов функции из scratch() заставляет линкер подключить кусочек import library, в котором находится трамплин, вот такой:
;; это в .text
_Sleep@4: jmp [__imp_Sleep@4]
..где __imp_Sleep@4 разрешается (при сборке PE Executable) в то место в .idata, куда попадает адрес настоящей функции из DLL.

Из потенциально-интересного нормальному человеку:
1. Механизм сломается на функциях, объявленных как __declspec(dllimport): при этом в точку вызова сразу компилируется косвенный вызов jmp [__imp_blabla], а трамплин отсутствует.
2. Поздняя привязка через LL/GPA дешевле на один трамплин + один косвенный вызов
3. Хорошей идеей представляется выпиливание всех этих собачьих суффиксов из sbcl.nm или при его парсинге. Вроде ничего не теряем, а получаем избавление от низкоинтеллектуальной деятельности (что подсчёт аргументов, что поиск функции в nm...) плюс лучшую переносимость на 64 бита (когда CloseHandle@4 внезапно становится просто CloseHandle, из-за того, что про ABI для платформы подумали заранее).

[akovalenko.livejournal.com]

3+. Сделал в виде "искать статические символы как по имени с @N, так и без него". Собирается. Работает. Закоммитил.

[(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.

[akovalenko.livejournal.com]

С тем, что такое «обычный mingw», тоже сейчас не всё ясно. Я хожу за mingw на mingw-w64.sourceforge.net (там лежат сборки под linux и windows хосты любой битности, для windows таргетов любой битности). Классический mingw, который 32 бита, берётся в другом месте. Однако, как я понимаю, в debian у меня под именем i586-mingw32msvc-gcc стоит именно он — и всё вышеупомянутое умеет -mno-cygwin и -mcygwin (будет забавно, если именно компилятор из комплекта cygwin — единственный, который не умеет)

у меня тоже нет 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}<)

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

[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 не висит. Сразу не понял, что к чему (я не помнил что у меня многопоточная версия). Сижу, как белый человек дальше работаю, и в бэкграунде мысль: "странно, как это получается..., вроде висеть должно".

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, кажется, понимаю, в чём дело.

[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)]

Спасбо за бинарник

[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() он всё равно никаким боком не относится.

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

Взял usocket из svn (ревизия 569). Стало лучше, но не совсем.

Hunchentoot отдал браузеру свою default страницу. Но после этого произошла такая ошибка:

There is no applicable method for the generic function
#<STANDARD-GENERIC-FUNCTION SB-BSD-SOCKETS:SOCKET-MAKE-STREAM (1)>
when called with arguments (NIL :INPUT T :OUTPUT T :BUFFERING :FULL :ELEMENT-TYPE (UNSIGNED-BYTE 8)).
[Condition of type SIMPLE-ERROR]

Restarts:
0: [RETRY] Retry calling the generic function.
1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Hunchentoot listener (*:4242)" RUNNING {24D4F551}>)

Backtrace:
0: ((SB-PCL::FAST-METHOD NO-APPLICABLE-METHOD (T)) #<unavailable argument> # #<STANDARD-GENERIC-FUNCTION SB-BSD-SOCKETS:SOCKET-MAKE-STREAM (1)>)[:EXTERNAL]
1: (SB-PCL::CALL-NO-APPLICABLE-METHOD #<STANDARD-GENERIC-FUNCTION SB-BSD-SOCKETS:SOCKET-MAKE-STREAM (1)> (NIL :INPUT T :OUTPUT T :BUFFERING ...))
2: ((SB-PCL::FAST-METHOD USOCKET:SOCKET-ACCEPT (USOCKET:STREAM-SERVER-USOCKET)) # #<unavailable argument> #<USOCKET:STREAM-SERVER-USOCKET {24D4D5A1}>)[:EXTERNAL]
3: ((SB-PCL::FAST-METHOD HUNCHENTOOT:ACCEPT-CONNECTIONS (HUNCHENTOOT:ACCEPTOR)) #<unavailable argument> #<unavailable argument> #>HUNCHENTOOT:ACCEPTOR (host *, port 4242)<)
4: ((FLET #:WITHOUT-INTERRUPTS-BODY-[BLOCK365]370))
5: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
6: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]300))
7: (SB-THREAD::CALL-WITH-MUTEX ..)
8: (SB-THREAD::INITIAL-THREAD-FUNCTION)
9: ("foreign function: #x419DB7")
...

[akovalenko.livejournal.com]

(defmethod socket-accept ((socket stream-server-usocket) &key element-type)
  (with-mapped-conditions (socket)
     (let ((sock (sb-bsd-sockets:socket-accept (socket socket))))
       (when sock
	 (make-stream-socket
	  :socket sock
	  :stream (sb-bsd-sockets:socket-make-stream
		   sock
		   :input t :output t :buffering :full
		   :element-type (or element-type
				     (element-type socket))))))))

Вот такое вставьте вместо оригинала (добавлен (when sock...)) в usocket/backend/sbcl.lisp.

Вполне возможно, что у Дмитрия есть более разумное решение (он тоже писал, что обновление помогло, но не совсем — но не сообщал подробностей).