[Bordeaux-threads-devel] [PATCH] liftfix, fluids, default-special-bindings

[Stephen Compall]

Please consider that I had two goals with this implementation:

1. To make a component that could be used immediately in clsql-fluid
   and Weblocks.

2. To share the implementation for anyone else who might find it
   useful.

So it is probably better that someone else is the gatekeeper, as I
have other interests.

On Thu, Jan 8, 2009 at 1:46 PM, Martin Simmons <martin at lispworks.com> wrote:
> I have a few of questions about fluids:
>
> Do you like the gc-count idea or is it just an implementation hack?

clsql-fluid needs to return the database connections to the pool on
thread death.  Threads in Weblocks come and go as Hunchentoot spawns
and kills them.  This was the easiest way I could think of to do this,
as I would prefer to return them to the pool rather than disconnect
them.

> Are there advantages to implementing a fluid as an object (rather
> than, say, being named by a symbol)?  Would you typically keep
> references to fluid objects in data structures or are they usually
> stored in global variables?

In a data structure is the only place I currently store one.  Weblocks
users can open multiple "stores", say one per webapp, and each open
CLSQL store is backed by a connection pool and a fluid to manage
access to the pool.  Each database-backed object stores the relevant
"store" in a slot so it can lazily fetch joins and such; this part is
done by CLSQL proper.

> Similarly, is it important that the gc can remove unreferenced fluid
> objects containing values for threads that are still alive?

Not to me.

> I'm wondering if it would be better to implement a per-thread fluid table,
> rather than the current implementation of a per-fluid thread table.

I considered using the special bindings, but that would entail
immediately requiring all Weblocks users to shift from Hunchentoot
0.15.7 to the svn repo at bknr (which is not even mentioned at any of
the usual places to find out about Hunchentoot), besides the actual
port of Weblocks to said Hunchentoot, requiring all thread spawners to
use bordeaux-threads, etc.  Many Weblocks users don't even use the
CLSQL backend, so this would hardly be fair to them.

If you want to see more about the context in which I wrote this, see
http://weblocks.lighthouseapp.com/projects/18897/tickets/61

-- 
Sorry but you say Nibiru is a Hoax?  Doesnt Exist?  So maybe The
Sumerian people doesnt exist also! --Anonymous by way of SkI