Bear with me here, I'm doing some brainstorming.
Consider the scenario of doing what could be considered your typical,
buzzword compliant, modern Client-Server data processing application.
Actually, it is a bit atypical as there will, conceptually, be LOTS of
users.
There will be idiot-savant clients, business savy server and finally
data servers. The whole zany thing has to scale.
A conventional solution would be to have a central box, accepting
client request and launching off the specific applications each with
their own process that then talk to the clients. These processes could
be any UNIX program, written in most anything.
But I'm thinking that it would be better if rather than launching off
all of these processes, that instead you could have a monolithic,
threaded Lisp image that is handling requests.
What would be the advantage?
Using typical Lisp programming techniques, I think that Lisp thread
programming would be generally safer than C thread programming. With
all of these threaded servers popping up, so are the horrors that make
folks hate DOS, Windows, and the Mac - rogue threads smashing and
corrupting happy, healthy threads because (maybe I'm mistaken here) the
grand benefit of memory protection is thrown out the window in a
threaded environment. So, technically, Lisp threads can be almost as
safe as generic Unix processes, without the overhead of a process,
barring an evil bug in the Lisp compiler.
But also, from a support point of view, I think that if you had this
large Lisp image out there, running and maintaining its own thread
environments, it is farily easy to have someone connect to the image
and look at specific threads and applications while using something
hardly more sophisticated than a read-eval-print loop.
If Tony in Purchasing calls up with a problem, it would be pretty
simple to "connect" to his instance, watch what they're doing, and,
perhaps, give them a procedural solution or even go in and "tweak"
something right there online. How WISE that solution might be is up
for question, but it should be possible.
I only really question how modules are changed and updated. Whether
that is possible/practical without bringing down the image.
I guess this would be a similiar solution to what may have happened if
Lisp Machines continued to grow and prosper.
But on the other hand, this is no different from how modern DBMS
servers are implemented. Throw the DBMS on the server, give 500 of the
512MB of memory to the DBMS, and they run off managing their own
thread, connections, etc. They let you probe and look, but you can't
touch.
What can't an application server be done the same way? How many DBMS
servers are acting as application servers with zillions of lines of
stored procedure code running about?
Is this a silly, impractical idea?
We talk about Lisp being a dynamic language, and handling dynamic
programs. Could the modern implementations handle the dynamics of
handling on the fly changes in a large, continuous running image with
multiple threads fighting for resources? Reaching into a dead patient
for a quick cardiac massage, perhaps?
I'm kind of hoping its doable, practical, and I would even say a
conservative approach. I'm also hoping that it is demonstrable using
something like the ACL/Linux package coming down the pike, or some
other implementation.
Any thoughts are appreciated.
--
Will Hartung - Rancho Santa Margarita. It's a dry heat. ······@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck