[postmodern-devel] is postmodern thread safe

[Ryszard Szopa]

On 10/2/07, Samantha Atkins <sjatkins at mac.com> wrote:

> Is WITH-CONNECTION getting threads out of a pool?  It seemed to
> optionally to do that but my early reading also made me wonder if
> those were active connections or still had some overhead before they
> could be used.  My own project idea was to take my ample (20+ years)

WITH-CONNECTION (and in fact any function/macro that deals with a
connection) takes a POOLEDP argument. If it is non-NIL, a connection
is recycled from the connection pool (if available). I don't *know*
(in the sense I haven't really digged in that code or made thorough
tests) if it works, but it *seems* to work and I kind of trust Marijn
when he says it works.

> of object persistence experience and produce a oodbms equivalent layer
> that can sit on any relational or many other underlying stores.  The
> ideas is that this layer can be used by any language front end to as
> transparently as possible persist objects, structures and
> relationships between them with consistent transaction support,
> concurrency, caching and throughput mostly independent of front end
> language efficiency.

Well, Common Lisp thanks to CLOS and the MetaObject Protocol [1] seems
like the perfect language to write something like that. Postmodern is
also a good choice, because its "getting in the way" factor is very,
very low (I think that keeping it maximally unobtrusive was one of
Marijn's design goals).

The problematic part in writing an object persistency library remains
(at least for me: I'm working on Submarine [2]) maintaining the
balance between use comfort and efficiency. To make a long story
short, making things happen naturally from the CLOS programmer (and I
think any object system programmer) point of view sometimes leads to
producing highly inefficient code...

For an extreme example, one could easily overload
slot-setting/slot-reading by updating/reading the values of columns in
some table, and that could be (from the programmer's point of view)
quite comfortable. Of course, this would be inefficient to death. I
still have hope, however, that there exist smart ways of generating
nice SQL code under the hood. I am still astonished by the stupidity
of some fragments of my own Postmodern/SQL code in Submarine, so I
predict I still have plenty of room for optimization, without loosing
the nice features or a rewrite from scratch :) After all, Common Lisp
is such a nice language for generating code in lesser ;) languages,
like SQL.

> Obviously this layer needs to be seriously multi-threaded.  I
> sometimes have doubts about doing this project in Lisp because things
> like threading support are not consistent and dependable on all
> platforms using non-proprietary Lisp.    Lisp is attractive to me for
> the mileage I can get in the way of generated specialized code and on
> the fly refactoring and other reactive programming tricks.  It also
> can come in very handy for offering a very full object query language
> that produces much more optimal code than less capable languages can
> support.   But the meat of such a layer could certainly easily be done
> in C# (I most of that "meat" in Java a while back) with much more
> portability and some serious other advantages like being able to be
> used fully in a single process for any .net/mono capable language.

There are Bordeaux threads, which is a semi-standard thread
compatibility layer between different CL implementations. Threads in
CL remain a bit tricky, though.

Best regards,

    -- Richard

[1] Bear in mind, however, that MOP is not standardized and its
implementation may differ drastically between different CL
implementations. Of course, there is Closer-MOP, but that doesn't
solve all the problems (e.g. slot objects in Lispworks don't know
which class they are belong to, while in SBCL they do).

[2] My very own object persistency library:
http://common-lisp.net/project/submarine/. For the record, I *did*
resist the temptation of advertising it in this thread ;-) (sometimes
I have the feeling that writing an object persistency layer should be
consed to every Lisp hacker's TODO list, the one already containing
writing his/her own scheme dialect and planting a tree).
-- 
http://szopa.tasak.gda.pl/