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] |
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.