Smalltalk + object databases

[astar]

I see what you mean. But SBCL these days have pretty much all of linux threading available. It does some magic with signals and so on, so if you load other libraries that depend on that, it's sometimes problematic, but otherwise it works pretty well. It also has atomic compare and swap instructions (as well as OS level condition variables and like, but CAS instructions are faster because it does not depend on having to change process context, flush pipelines, go into kernel context, and so on.)

[Patrik]

sure, in many cases one doesn't need separate server process. my thinking is more as a backend for a more distributed system providing many services that naturally lives on different machines.

[astar]

That's also possible. The early lisp based web servers did something like that. The socket connections show up as gray streams, and you can do regular reads / writes / block writes on them. I mean there is nothing about which programming language you program in to have os processes talk to each other, right?

[Patrik]

nope. not at all - you may have misunderstood me. i'm coming from it as starting to think about object databases (via playing with gemstone/s), and outside of gemstone/s not finding object databases that are not oriented towards embedded use. i'd need the same data/objects to be accessible from many processes on many machines - ideally without having to write a server layer on top of an embedded db, inventing a client protocol etc etc.



i have some things that are implemented in jruby, using embedded neo4j graphdb, a client protocol in protobuf and transport using zeromq (clients can be in any language that has a zeromq and protobuf binding). that's not bad at all, but a thing like gemstone/s has a lot less complexity and more maturity so would be interested in exploring anything like that in any language.



btw, there's now maglev-ruby which is ruby on gemstone/s. pretty cool but still early days.

[astar]

Now I think I understand what you mean by embedded use. Basically whether the system supports having multiple memory images/runtimes access the same data.



If so, some of the lisp solutions will support multi-process access/update, basically the ones that uses a real multiuser database at the back, and others might or might not.



The protocol buffer based ways of passing objects around is probably the cleanest way I have seen to do this sort of thing. Once you can treat objects as immutable values, a lot of programming problems disappear. But if you need something like persistent objects with different processes simultaneously accessing/modifying it, and maintaining object identity, yeah, I dont know any system out of the box.