Cyber Surfer <cyber_surfer@nospam.wildcard.demon.co.uk> wrote:
+---------------
| > Or are using a system such as Unix in which "processes" are considered
| > to be composable elements of tasks. I wonder how you would deal with
| > the notion of, say, CGI-BIN scripts if the HTTP server and the CGI-BIN
| > interpreter/compiled-language were *not* [for whatever reason] the same
| > memory image or even written in the same language?
|
| Some servers let you put your CGI code into dynamically linked
| libraries. The server loads the code on demand, and unloaded after an
| inactivity timeout. There's support using this technique with Perl,
| Prolog, and soon Smalltalk. It should also be possible to add such
| support to a Lisp that supports DLLs, like ILOG Talk.
+---------------
That only works if your server is written in a language whose calling
sequences are compatible with the language your CGI-BINs-in-a-DLL are
written in. Which starts to look like a "single-language system" again --
nice in theory but not generally applicable in the broader market.
Or else you load up the HTTP server with all the complexity to handle
all the FFIs to all those languages. Again, not possible unless you
control the server.
+---------------
| > It is for applications like this -- as well as writing other "small"
| > scripts (and/or compiled programs) intended to be used in Unix pipes --
| > that I am concerned about start-up time.
|
| Ah, yes. Unix. I'm told that not all Unices support dynamically linked
| libraries.
+---------------
Again, DLLs are not really the issue -- single-process vs multi-process is.
Without loss of generality, let's assume for the moment that all Unix-like
systems support DLLs (or, as they are called more often in that environment,
DSOs), and that each of your CGI-BIN scripts are written using *some*
language that supports separating the program into a tiny "main" program
and a bigger DLL/DSO called by the "main". [Note that in Unix, DSOs aren't
themselves "executable"; they must be linked to by some running executable,
either their usual default "main" or some other running program, e.g., the
HTTP server. When an executable program that was link-edited against a set
of DSOs is run, this runtime linkage is automagic, e.g, via "rld". Or if
you want to bolt on a DSO you weren't linked with, you just call "dlopen()".]
In the Unix-like world, you're still left with the following issues:
1. The HTTP server must know how to identify those executables which are
written as tiny-main+DLL/DSO and which ones aren't. When called to
execute one that is, instead of fork/exec'ing the program (as it would
normally do for an executable) it must do a "dlopen()" of the DSO and
call the entry point that the tiny "main" would have called, with the
correct calling sequence and arguments. [I'm hand-waving over the
issue of most CGI-BINs being "scripts" which call interpreters to
execute them. I'm assuming that the server would be smart enough to
example the first line of a script, notice that it said "#!/path/to/foo",
try to assimilate the "foo" program's DSO, and call the appropriate
point (see below) with the appropriate args (see below), including a
filepath to the script.]
2. Each "main" may (in fact, almost always does!) have its own way
to pass command-line args to the DSO. How is the server to know?
(...without, say, decompiling the executable?) There are no common
standards in this area. (...unless the server has been configured
*ahead of time* for each and every language or application environment
it has to work with.)
3. Even if the server "knows" how to package up the info it would have
passed on the command line into a form acceptable to the DSO, is the
language the server is written in compatible with the runtime calling-
sequence conventions and the environment of the DSO? E.g., what if the
DSO contains its *own* garbage collector, incompatible with the server's?
+---------------
| If my employer had chosen Linux instead of NT for our web server, then
| I might now be writing CGI that uses dynamic linking, thus avoiding
| problems with startup issues.
+---------------
As noted above, merely having dynamic linking doesn't solve the problem.
Doesn't even come close!
-Rob
-----
Rob Warnock, 7L-551 rpw3@sgi.com
Silicon Graphics, Inc. http://reality.sgi.com/rpw3/
2011 N. Shoreline Blvd. Phone: 415-933-1673 FAX: 415-933-0979
Mountain View, CA 94043 PP-ASEL-IA