This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Guile Startup Time Suggestion


I have come in fairly late to the discussion of the Guile starup time.  I
am assuming that its startup time is similar to SCM.  From
reading the discussions most of the start time is taken up in
guile library files.

When I was working on embedding an interpreter into an application,
I seperated the user interface from the scheme interpreter and they
talked to one another usings sockets (TCP or UNIX) depending where
the interface and interpreter were.

Here is the suggestion.

Have Guile always running, as a user process
or as a system daemon.  The Guile process
has loaded whatever initialization files are needed.  This process is
always listening on a socket and accepts connections from user (front
end processes).  When a connection is accepted the Guile process
forks itself, thus being automatically intialized.  Guile would redirect
its stdin and stdout ports to the socket connection, thus acting like a
normal interpreter.

User comands, whether through a command line interpreter or script would be
sent to interpreter for reading and evaluation.  The result is sent back to
the user interface and displayed.

Then the startup time is basically the startup time
of the user interface.  The front end user process can be very small,
written in C with a minimal understanding of Guile syntax (Just what is
neccessary
to read Guile input and maybe interface with the interpreter using Guile
programs).

In Executing a script, the user writes a Guile script but
instead of using the line:

#! /usr/local/bin/guile -r

uses

#! /usr/local/bin/guile/scripter

The C scripter starts up, connects with the Guile process and writes
a string down the socket with the following form:

(guile-interface-negotiate '(process-id . 12347653)
  '(working-directory . "/home/humeniuw/"))

The Guile process responds with

#t

accepting the negotiation.

Then the scripter issues

(load "/home/humeniuw/script.scm")

The script excutes and the user readable response is sent the
user interface, it displays it, closes the connection, and the Guile
process exits.  Finished.

I am not exactly a Unix system person but if running as a daemon could
the ownership of the Guile fork be transferred to the interface process?
The user interface and the interpreter would negotiate initial parameters
like pid and the current working directory.