[elephant-devel] sbcl-64 tests

[Ian Eslick]

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 at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel