Not OT at all...
On Thu, Apr 26, 2001 at 06:24:41PM +0200, Issac Goldstand wrote:
>
> Can any of the mod_perl 2 people provide some feedbak on this, as I'm
> sure you guys have looked at this much deeper than I have.
Well, I'm not a "mod_perl 2" person, but I can say that PerlInterpScope
(it's been renamed) merely lets you control whether interpreter threads
are allocated per HTTP request/subrequest/handler call/connection, not
associate an interp with a client. The 'connection' option (I think)
looks like it's mostly for more session oriented protocols, the FM
(modperl_2.0.pod) mentions ftp.
If you wanted to muck about in C or with your own protocol handler, you
could take some session ID (cookie, URL, say, just not the client's IP
address) and direct it to a particular thread, but...
You probably don't want intepreters devoted to individual clients
whether they be in threads or in processes. Waste of good memory, that.
It might help in rare circumstances with keepalives (pure conjecture
here), but keepalives don't guarantee that the client will only make one
connection. Without keepalives on, most popular browsers make multiple
connections to the server and can keep several connections busy at once.
That's still technically possible with keepalives, though I don't know
if any browsers try to open multiple kept-alive connections
intentionally (though they can if a server has more than one IP & host
name).
Closer to what you're thinking of are the 'solar' variables Doug
mentions wistfully. But unless you back the in-memory store to a disk
or something, you lose on server shutdown, which takes you back to
conventional session management techniques, although it does look like
you could share some fewer number of database connections or open
filehandles between your threads to do this using Doug's wrappers around
Apache's memory pools.
- Barrie
