This is the mail archive of the guile@sourceware.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]

RE: Guile web page scripting, anyone?




	> I suppose the main one is how do I get Guile to interpret the code?
	> Now, it's not as dumb a question as it appears.  What I really want is
a
	> library that'll allow something like:
	> 
	>         initialise_guile () -- does all the difficult startup stuff,
just
	> executed once per web server

	Unfortunately there is nothing like this. However, a while back I wrote
	a patch to add support for a gh_init() call which could be used this way
	instead of using gh_enter(). I will check in this code in the course of
	catching up on the the general Guile patch backlog.

An old school approach I use in an instrument control program which works well
for me is to have the master server fork a scheme process on startup (right now
it's still scm but I'll switch to guile when I get the time), i.e. the classic
preforked children approach.  I have used both sockets and more recently shared
memory and semaphores to control the communication, also both standard
approaches.   As time goes on, more of the C routines for instrument control get
wrapped in scheme.  There are other preforked childred, in C, to handle other
tasks (communication, display, data handling, ...).  The master is small and
pretty robust (no crashes in ~2 years or frequent use).

I would think that modern web servers would allow this approach.  By using a
fork() and exec() approach with a predefined data structure for passing through
shared memory it is possible to run a program in any language as the add on
interpreter.  For me at least the communication overhead is small (shared memory
and compared with the scheme evaluation speed)

	>         create_instance () - does any initialisation required to set
up a new
	> instance of Guile for each web page we're working with.

	Guile does not support the creation of multiple separate interpreters in
	one program. However, with the first-class environment patch, you should
	be able to evaluate code in a fresh environment each time to get much
the
	same effect. A patch for this is also on my queue.

The preforked child approach does not scale well to having many simultaneous
interpretters running.  However, my problems tend to be serial in nature, or I
serialize them.  Since computational tasks are serial (per processor) this
should not affect performance drastically.


-John
	 



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