search

cosmos72 / stmx

High performance Transactional Memory for Common Lisp
http://stmx.org/
244 stars 14 forks source link

Does not work with sbcl 1.4.10 - internals change #14

Closed quicklisp closed 4 years ago

quicklisp commented 6 years ago

Build log is here: http://report.quicklisp.org/2018-07-27/failure-report/stmx.html#stmx

cosmos72 commented 6 years ago

I will have to ask how to update assembler-building functions for sbcl 1.4.10 on sbcl-devel mailing list

quicklisp commented 6 years ago

Any word on this?

cosmos72 commented 6 years ago

Not yet, sorry. I am currently very busy, any kind of help on this would be much appreciated

AeroNotix commented 6 years ago

15 lets stmx compile and complete tests on sbcl 1.4.10.

cosmos72 commented 6 years ago

As discussed in https://github.com/cosmos72/stmx/pull/15, commit e54d768fd3e389041363993ffad18747f34469ed should fix stmx to work on SBCL 1.4.10+ as well as older versions.

Now backporting it to the stable branch, used by quicklisp

cosmos72 commented 6 years ago

fix backported to stable in commit e17f39dbbbf01a8dc8ce08f173177366f04b6194

Harleqin commented 5 years ago

It seems that https://github.com/AeroNotix/stmx/commit/2d0bf468fa2f16da81f10242bd4673324810b648 did not yet make it into this repo. From https://stackoverflow.com/questions/55961071/using-library-functions-in-multi-threaded-code-common-lisp/55967338?noredirect=1#comment98608614_55967338:

Also, on Linux Mint the error is caught ERROR: READ error during COMPILE-FILE: Lock on package SB-VM violated when interning EMIT-SKIP while in package SB-X86-64-ASM. See also: The SBCL Manual, Node "Package Locks" (in form starting at line: 123, column: 0, position: 4767)

cosmos72 commented 5 years ago

The patch https://github.com/cosmos72/stmx/commit/e17f39dbbbf01a8dc8ce08f173177366f04b6194 was supposed to supersede https://github.com/AeroNotix/stmx/commit/2d0bf468fa2f16da81f10242bd4673324810b648, in order to support both sbcl < 1.40 and >= 1.4.0

I am checking right now if some fix is still missing, at the moment I tested the commands

(ql:quickload "stmx")
(ql:quickload "stmx.test")
(fiveam:run! 'stmx.test:suite)

with the following results:

stable branch, commit 4d915e334030d8b6a8a7c889c1a0557da9a64028 (published on quicklisp and github)

master branch, commit 805bbc1389bdeaec9e1a054154fb3f23f709062c (published on github)

I will do more tests and update this post accordingly. Question: is it possible that the original reporter somehow used an old version of stmx?

davypough commented 5 years ago

With reference to issue #14, quickload problem @davypough was caused by out-of-date Quicklisp. Linux Mint now loads fine. However, I'm still getting a problem with quickload hanging in Windows after

(ql:quickload :stmx) -> To load "stmx": Load 1 ASDF system: stmx ; Loading "stmx" To load "log4cl": Load 2 ASDF systems: bordeaux-threads bt-semaphore Install 1 Quicklisp release: log4cl

Verson info (newest): Quicklisp Client 2019-02-16 Quicklisp dist 2019-03-07 Windows 10 version 1803 (OS Build 17134.753) Windows SBCL 1.4.14 AMD64

Update if it's of any help: found different error during (ql:quickload :stmx) this morning on SBCL+Windows10:

; in: DEFUN START-HIERARCHY-WATCHER-THREAD ; (LOG4CL-IMPL:LOG-DEBUG "Watcher thread already started") ; ; caught ERROR: ; during macroexpansion of (LOG-DEBUG "Watcher thread already started"). Use ; BREAK-ON-SIGNALS to intercept. ; ; The value ; "WITHOUT-INTERRUPTS-BODY-1" ; is not of type ; LIST

cosmos72 commented 5 years ago

Currently I don't have a Windows 10 box to try. My tests on Windows 7 passed (read: I could not reproduce your problem), but SBCL 1.4.14 startup message on Windows is noteworthy:

WARNING: the Windows port is fragile, particularly for multithreaded
code.  Unfortunately, the development team currently lacks the time
and resources this platform demands.

I would not rely on SBCL+Windows for heavily multi-threaded code, unless you are willing to help SBCL core team in troubleshooting the issues you may find.

One thing you can try is to press CTRL+C and see whether SBCL shows where it is stuck (it must be pressed twice in Emacs+SLIME). From your log, it appears to be stuck installing log4cl, but without further details it may be misleading.

davypough commented 5 years ago

OK, but my comment was related to quickloading log4cl as part of smtx.

From: Massimiliano Ghilardi [mailto:notifications@github.com] Sent: Saturday, May 4, 2019 12:08 PM To: cosmos72/stmx stmx@noreply.github.com Cc: Dave Brown davypough@gmail.com; Mention mention@noreply.github.com Subject: Re: [cosmos72/stmx] Does not work with sbcl 1.4.10 - internals change (#14)

Currently I don't have a Windows 10 box to try. My tests on Windows 7 passed, but sbcl startup message on Windows is noteworthy:

WARNING: the Windows port is fragile, particularly for multithreaded code. Unfortunately, the development team currently lacks the time and resources this platform demands.

I would not rely on this port for heavily multi-threaded code, unless you are willing to help SBCL core team in troubleshooting the issues you may find.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cosmos72/stmx/issues/14#issuecomment-489356285 , or mute the thread https://github.com/notifications/unsubscribe-auth/AAVNZ6OFFVRCEUO2WZQMRALPTXNKHANCNFSM4FMN6FDQ . https://github.com/notifications/beacon/AAVNZ6M7NU5GGCXXVASLLJ3PTXNKHA5CNFSM4FMN6FD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODUVPX7I.gif

cosmos72 commented 4 years ago

Sorry for the long delay.

Unluckily I do not have the resources/expertise to troubleshoot issues related to log4cl, especially on Windows, even if they happen while loading stmx.

I can only "vaguely" state that it seems a thread-related issue, specific to the combination windows+sbcl+log4cl, because the source code (LOG-DEBUG "Watcher thread already started") triggering the error is inside log4cl, in the file watcher.lisp - not inside stmx.

You may get a better outcome by asking in log4cl forums, especially if you get reproduce the same error with a command involving fewer dependencies - maybe (quickload "log4cl") ?