On Thu, 2009-01-08 at 19:21 +0000, Martin Simmons wrote:

...

...

...

...

...

On Sun, 28 Dec 2008 18:06:44 +0100, Stelian Ionescu said:

On Sat, 2008-12-27 at 21:10 -0600, Stephen Compall wrote:

...

and *default-special-bindings*.

pushed with a few modifications

I also added default initialization forms to *default-special-bindings*: the rebound specials are those bound by with-standard-io-syntax, with the addition of *break-on-signals* and *random-state*

I think those default initializations are a bad idea. Anyone setting them globally either wants that effect or needs to learn about let. Conversely, it could be quite annoying not to be able to set *break-on-signals* for all threads.

Good point. I removed the default bindings of *break-on-signals* and *random-state* leaving only those bound by with-standard-io-syntax. I also added a new keyword argument to make-thread: initial-bindings which defaults to *default-special-bindings*.

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@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