Integrating guile into an existing multi-threaded application

Integrating guile into an existing multi-threaded application

[Charlie Root]

Hi,

Yes, another pthread question. I've been through the list archives,
read what docs there are, looked a bit at the code, and had a few
questions answered. But before I take off in the wrong direction, I'd
appreciate some advice.

I am considering using guile inside an existing multi-threaded
(pthreads, solaris 2.6,7,8) application. I'm aware of many of the limitations
(at least as of October 2001, which is the latest message I've seen on
the issue) including using guile inside a single thread. So here's a
proposed sketch of the project. Any obvious faulty thinking?


We have a client-server architecture. Data enters the client, and is
passed to the server. At startup, the server loads an arbitrary number of
processing modules. When the server receives a data packet from the
client, it spawns a processing thread. This thread runs the data
through each of the processing modules in sequence. Many of these
threads (thousands, sometimes) exist simultaneously.

What I want to do is to write a processing module which uses Guile. 
The module will load its (scheme) processing commands at startup, and
munge data using this scheme code when called from a processing thread. 
As a bonus constraint, I'm not allowed to modify the server itself.

So far as I can tell, this means that the guile module will need to
spawn an interpreter thread at server startup time, and then when it
processes a data packet, send the data off to the interpreter thread
and wait for a response. Probably the guile call will be gh_eval_str(),
since I will be feeding it data and waiting for responses to pull back
into C.

Now, this is kind-of asking for a bottleneck right there, but I can
imagine using guile's threads to ease it somewhat if it becomes a
problem. So here are some questions:

 . The guile interpreter may not be fired up by the process's
   main thread, but some other one, and at some other time than 
   the end of main(). Is this a problem?

 . I don't understand the arguments to gh_enter(). The main 
   thread's argc and argv will not be available to 
   gh_enter(). If the `inner_main' of gh_enter() is not going
   to need data passed to it, can these contain dummy values?

 . Will I be able to use guile's threads inside a system such as
   the one described (that is, inside a non-main thread) ?

 . Are there other obvious-to-the-seasoned-guiler sorts of issues
   that I'd do better with if I knew of in advance?

Any thoughts on the situation are actively solicited.

Thanks a whole bunch,
-CR

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Integrating guile into an existing multi-threaded application

[Thien-Thi Nguyen]

   From: Charlie Root <uucp@rocketmail.com>
   Date: Tue, 4 Jun 2002 22:53:17 -0700 (PDT)

   Any thoughts on the situation are actively solicited.

just found Mark Hays' excellent pthreads tutorial:

 http://www.math.arizona.edu/swig/pthreads/threads.html

perhaps it would be useful to experiment w/ integrating guile and seeing
what works, and then publishing the results.  this is what i would do if
i had another few hours every day...  if you go this route, i'm happy to
host your findings under http://www.glug.org/docbits/

this is how we can battle ignorance together.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Integrating guile into an existing multi-threaded application

[Marius Vollmer]

Charlie Root <uucp@rocketmail.com> writes:

>  . The guile interpreter may not be fired up by the process's
>    main thread, but some other one, and at some other time than 
>    the end of main(). Is this a problem?

Probably not.  You should be using scm_boot_guile instead of
scm_init_guile, tho, since the latter might not be able to find the
correct stack base in non-main thread.  scm_boot_guile uses the
address of a local variable as the stack base.  A consequence is that
the callback given to scm_boot_guile should never return since
scm_boot_guile will terminate the process then.

(See below why I don't talk about gh_enter here.)

>  . I don't understand the arguments to gh_enter(). The main 
>    thread's argc and argv will not be available to 
>    gh_enter(). If the `inner_main' of gh_enter() is not going
>    to need data passed to it, can these contain dummy values?

Use scm_boot_guile instead of gh_enter since the gh_ interface will
eventually go away.  We will make the scm_ API easy enough to use
instead.  It is reasonably easy already, I hope.

scm_boot_guile has the same argc and argv arguments as gh_enter.
From the manual:

     `scm_boot_guile' arranges for the Scheme `command-line' function
     to return the strings given by ARGC and ARGV.  If MAIN_FUNC
     modifies ARGC or ARGV, it should call `scm_set_program_arguments'
     with the final list, so Scheme code will know which arguments have
     been processed.

So, you can pass any valid value.  scm_boot_guile (0, NULL, ...)
should be fine.  This will make 'command-line' return the empty list.

>  . Will I be able to use guile's threads inside a system such as
>    the one described (that is, inside a non-main thread) ?

Yes, I think so although I myself have never done it.

>  . Are there other obvious-to-the-seasoned-guiler sorts of issues
>    that I'd do better with if I knew of in advance?

Be careful to always protect your global SCM values and to unprotect
them when they die.  And, try to use scm_ instead of gh_ functions.
If you find you can't do that, yell.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user