[bknr-devel] Recursive locks problem on sbcl
Hi Hans, the problem we've spoken of yesterday on irc (recursive lock attempt warning on sbcl using bknr datastore) proved to be trivial to solve - there is a primitive in sb-thread for exactly this case. I have not tested it extensively yet, but it appears to work. The patch is attached. FWIW, being unable to load some third-party libraries supplied with bknr (mainly cxml and unit-test), I ditched thirdparty altogether, installed all the newest versions of whatever bknr-indices and bknr-datastore depend on, and both seem to work. Thanks, Denis (oudeis).
On Tue, Oct 02 2007, Denis Mashkevich wrote:
Hi Hans, the problem we've spoken of yesterday on irc (recursive lock attempt warning on sbcl using bknr datastore) proved to be trivial to solve - there is a primitive in sb-thread for exactly this case. I have not tested it extensively yet, but it appears to work. The patch is attached.
Could you please elaborate on the problem? What happens with the datastore in SBCL without the patch?
FWIW, being unable to load some third-party libraries supplied with bknr (mainly cxml and unit-test), I ditched thirdparty altogether, installed all the newest versions of whatever bknr-indices and bknr-datastore depend on, and both seem to work.
Some time ago I wrote a patch that dumped cxml for the purpose of using cmucl-19d. Hans, do you think we can apply (some modified version of) it? Best regards, -- Kamen
Kamen, Hi, sorry for putting you on hold for so long. I did not have the time to review your patch when you sent it, and it now does no longer apply cleanly. Generally, I would like to continue to be able to get a BKNR based installation to run without having to turn to external sources, thus the thirdparty/ directory. I am aware that this is not a very good solution, but to me, this is better than having to follow upstream changes to thirdparty stuff all the time. Also, I have no immediate plans to upgrade my existing installations from cmucl-19c. Can you please re-send your patch as an attached file, against current BKNR? Does the patched version run with cmucl-19c? I will promptly apply and commit the patch if you send it soon. Sorry for the delay. Thanks, Hans 2007/10/2, Kamen TOMOV <kamen@cybuild.com>:
On Tue, Oct 02 2007, Denis Mashkevich wrote:
Hi Hans, the problem we've spoken of yesterday on irc (recursive lock attempt warning on sbcl using bknr datastore) proved to be trivial to solve - there is a primitive in sb-thread for exactly this case. I have not tested it extensively yet, but it appears to work. The patch is attached.
Could you please elaborate on the problem? What happens with the datastore in SBCL without the patch?
FWIW, being unable to load some third-party libraries supplied with bknr (mainly cxml and unit-test), I ditched thirdparty altogether, installed all the newest versions of whatever bknr-indices and bknr-datastore depend on, and both seem to work.
Some time ago I wrote a patch that dumped cxml for the purpose of using cmucl-19d. Hans, do you think we can apply (some modified version of) it?
Best regards,
-- Kamen _______________________________________________ bknr-devel mailing list bknr-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/bknr-devel
Hans, It's OK. I've updated to the current version and I'm provding the patch as a file. With this patch BKNR will continue to run without relying on external sources. The patched version will work on cmucl-19c as there aren't any changes beside code reorganisation. Here is my original message:
CXML continued breaking the compilation so I isolated it completely from bknr-datastore. In order to do so I had to remove two dependancies - one in the bknr-utils package and one in bknr-indices.
The dependancy in bknr-indices appears to be bogus and it was easy to remove. The dependancy in bknr-utils was not and in fact it might need a bit more work. Generally, I created a new module "xml" where I put the removed functionality. I don't know if this is the best idea (perhaps it belongs to some other module).
I am sending you the diffs. I haven't tested it because I don't use many of the modules. I have worked only in the bknr/src directory so it might break stuff in your projects.
Generally, it would be best if there are no dependancies, but as nothing is perfect let's make them less. Parhaps bknr-utils can be shortened more, but currently I do not have an immediate need for that.
Regards, -- Камен ----- Original Message ----- From: Hans Hübner Sent: 02 Oct 2007 at 14:13 Subject: Re: [bknr-devel] Recursive locks problem on sbcl Kamen, Hi, sorry for putting you on hold for so long. I did not have the time to review your patch when you sent it, and it now does no longer apply cleanly. Generally, I would like to continue to be able to get a BKNR based installation to run without having to turn to external sources, thus the thirdparty/ directory. I am aware that this is not a very good solution, but to me, this is better than having to follow upstream changes to thirdparty stuff all the time. Also, I have no immediate plans to upgrade my existing installations from cmucl-19c. Can you please re-send your patch as an attached file, against current BKNR? Does the patched version run with cmucl-19c? I will promptly apply and commit the patch if you send it soon. Sorry for the delay. Thanks, Hans
On Oct 2, 2007, at 12:48 PM, Kamen TOMOV wrote:
On Tue, Oct 02 2007, Denis Mashkevich wrote:
Hi Hans, the problem we've spoken of yesterday on irc (recursive lock attempt warning on sbcl using bknr datastore) proved to be trivial to solve - there is a primitive in sb-thread for exactly this case. I have not tested it extensively yet, but it appears to work. The patch is attached.
Could you please elaborate on the problem? What happens with the datastore in SBCL without the patch?
Hi Kamen, here is the context of the discussion: trying mp-store on sbcl/linux, i get this: recursive lock attempt #S(SB-THREAD:MUTEX :NAME NIL :VALUE #<SB- THREAD:THREAD "initial thread" {A6C5721}>) executing incf-counter from the tutorial this is a warning, after which sbcl stops responding Denis
participants (3)
-
Denis Mashkevich -
Hans Hübner -
Kamen TOMOV