I was in the middle of doing some similar changes in memutil to
support 64-bit (the files are still local on my machine). Marco
Baringer also did some work on 64-bit compliance. Are you willing/
ready to forward your changes to me so we can have a discussion about
the best way to update the CVS for 64-bit lisps?
I think I've seen the drop-instances problem before, but not for
awhile. I'll look into it as part of 0.6.1. Is it intermittent or
reproducible?
Thanks,
Ian
PS - On your multithreading observation. Berkeley DB is definitely
setup to use parallel processes. Briefly, you link to the BDB
library. When you open a DB there's an on-disk environment that is
initialized and shared among all processes. This indexes into a
shared memory region that is used to store locks, transactions,
cached pages, logs, etc. The BDB functions themselves handle
blocking on locks and arbitrating between different processes.
There's several ways to do this across machines as well (transaction
server or distributed transactions) but I haven't looked into this much.
On Jan 23, 2007, at 7:42 PM, Henrik Hjelte wrote:
I have started running the bdb backendtests on latest sbcl, amd64
linux.
I also have got a beta snapshot of openmcl-linux-64 (2006-12-31)
running
sometimes. I don't know how stable this beta is, but at least it's
good
to run several lisps to find bugs.
When running the backend tests for bdb on sbcl, the first failure was
the FIXNUM test. It serializes/deserializes most-positive-fixnum.
Since
most-positive-fixnum was larger than 32bit integers, I somehow
suspected
64 bit problems. Which was not the main problem. Instead it was
related
to the type checking in the serializer. I have attached a solution
in a
diff-file.
(A parenthesis: My 64-bit adventures gave some code as a sideffect. I
have added 64 bit integers to memutils.c and refactored/obscured it
with
a macro that makes the reader and writer functions. I have changed all
references to int to be explict int32 in memutils.lisp and
bdb-controller. I have a half-finished version of bdb-controller with
macros making the cursor movement methods. I'll keep it in the
closet if
it's of any use later on. End of parenthesis)
Now almost all backendtests run.
2 out of 115 total tests failed: INDEXING-WIPE-INDEX, INDEXING-TIMING.
Index-timing fails with this error. This is something I have noted
before with my recent experiments with elephant version 6. Suddently
after deleting instances, elephant would sometimes say that the class
was no longer indexed. I think it showed up with both the bdb and the
clsql backend. Has no one else noticed this? Below is a backtrace, you
can see the drop-instances call which I am suspecting.
About multithreading/testing. I volunteer to add some kind of
stress-test with bourdeaux threads later, but now the outstanding
bug is
a blocker.
Speaking of multithreading: since few Lisp:s use native threads, and
writing thread-safe code can be difficult, in my opinion taking
advantage of multi-core processors is most easily done with spreading
processes. what about multiprocessing? I mean parallel Lisp instances,
on the same or different computers, writing and reading to the same
database? Is elephant supposed to work in that kind of environment. I
suppose the clsql backend does, but what about bdb?
That's all for now, it's in the middle of the night for me, got to
count
some sheep.
/Henrik Hjelte
Class #<PERSISTENT-METACLASS STRESS-INDEX> is not an indexed class
[Condition of type SIMPLE-ERROR]
Restarts:
0: [ABORT] Return to SLIME's top level.
1: [TERMINATE-THREAD] Terminate this thread (#<THREAD
"worker" {1004E89801}>)
Backtrace:
0: ((SB-PCL::FAST-METHOD FIND-CLASS-INDEX (PERSISTENT-METACLASS))
#<unused argument>
#<unused argument>
#<PERSISTENT-METACLASS STRESS-INDEX>
:SC
NIL
:ERRORP
T)
1: ((LAMBDA ()))
2: ((SB-PCL::FAST-METHOD ELEPHANT::EXECUTE-TRANSACTION
(DB-BDB::BDB-STORE-CONTROLLER #1="#<...>" . #1#))
#<unused argument>
#<unused argument>
#<DB-BDB::BDB-STORE-CONTROLLER {1004E9A2D1}>
#<CLOSURE (LAMBDA #) {10049CE119}>
:TRANSACTION
NIL
:ENVIRONMENT
NIL ..)
3: (DROP-INSTANCES
(#<STRESS-INDEX {10049CBB51}> #<STRESS-INDEX {10049CA331}>
<diff-last-4-changes>
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
