Guile Interpreter as a Standalone Server

Guile Interpreter as a Standalone Server

[Volkan YAZICI]

Hi,

I need such a feature:

  /*
   * If there's an already running guile process in the background,
   * return it, otherwise create a new one and return new process.
   */
  interp = guile_interp(...);

With such a functionality, it'd be possible to

 - Parse & execute faster. (We won't need to create a new process
   everytime.)
 - Cache parse plans.
 - Use global variables that's accessible by any process using the
   same interpreter.

Is such a feature already supported by Guile? Can I achieve above 3
functionalities with using another method?


Regards.


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

Re: Guile Interpreter as a Standalone Server

[Ludovic Courtès]

Hi,

Looks like nobody answered you, so here we go.

Volkan YAZICI <yazicivo@ttnet.net.tr> writes:

> I need such a feature:
>
>   /*
>    * If there's an already running guile process in the background,
>    * return it, otherwise create a new one and return new process.
>    */
>   interp = guile_interp(...);
>
> With such a functionality, it'd be possible to
>
>  - Parse & execute faster. (We won't need to create a new process
>    everytime.)
>  - Cache parse plans.
>  - Use global variables that's accessible by any process using the
>    same interpreter.
>
> Is such a feature already supported by Guile? Can I achieve above 3
> functionalities with using another method?

Neil's new debugging framework (`guile-debugging', available in CVS HEAD
or on gna.org [0]) has support to send code for execution to a remote
Guile process so that might be useful to you.

However, as far as improving efficiency is concerned, I do not think
that running a single process is the right approach.  Profiling and then
improving Guile's startup may be a smarter approach.  ;-)

As for sharing information among processes: One could argue that the
notion of a process (and address space) is only vital for
non-memory-safe languages (such as C), and that memory-safe languages
(such as Scheme and Java) do not need such a mechanism because they
already provide other mechanisms to achieve memory safety (closures,
module systems, etc. --- see [1] on that topic).

Thus, providing mechanisms to share information among "processes" (or
"modules", or "programs") would more likely be the job of a "shell",
i.e., some sort of an enhanced REPL that has all the authority of the
user behind the keyboard (i.e., it can access all the data, programs and
resources the user has access to).  GUSH (``GNU User's Shell'') was more
or less an attempt to provide such a shell based on Guile, and indeed,
it would have been able to execute any Guile program _within_ the GUSH
process.  SCSH [2] is similar to that, and there's also a Guile port [3]
(not sure whether this is the last version).

Hope this helps,
Ludovic.

[0] https://gna.org/projects/guile-debugging
[1] Jonathan Rees, "A Security Kernel Based on the Lambda-Calculus",
    http://mumble.net/~jar/pubs/secureos/ --- a enlightening paper.
[2] http://scsh.net/
[3] http://arglist.com/guile/


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

Re: Guile Interpreter as a Standalone Server

[Volkan YAZICI]

Hi,

On Oct 13 02:30, Ludovic Courtès wrote:
> Looks like nobody answered you, so here we go.

Thanks so much for your detailed post. I solved (a small part of) my
problem by invoking scm_init_guile() just at the start of the backend
process. (But caching parse plans is still a PITA for now.) OTOH, in
this design I've some other problems about restoring global values after
execution code supplied by the user. (I'll talk about this later in
another thread.)

> Neil's new debugging framework (`guile-debugging', available in CVS HEAD
> or on gna.org [0]) has support to send code for execution to a remote
> Guile process so that might be useful to you.
> 
> However, as far as improving efficiency is concerned, I do not think
> that running a single process is the right approach.  Profiling and then
> improving Guile's startup may be a smarter approach.  ;-)
> 
> As for sharing information among processes: One could argue that the
> notion of a process (and address space) is only vital for
> non-memory-safe languages (such as C), and that memory-safe languages
> (such as Scheme and Java) do not need such a mechanism because they
> already provide other mechanisms to achieve memory safety (closures,
> module systems, etc. --- see [1] on that topic).
> 
> Thus, providing mechanisms to share information among "processes" (or
> "modules", or "programs") would more likely be the job of a "shell",
> i.e., some sort of an enhanced REPL that has all the authority of the
> user behind the keyboard (i.e., it can access all the data, programs and
> resources the user has access to).  GUSH (``GNU User's Shell'') was more
> or less an attempt to provide such a shell based on Guile, and indeed,
> it would have been able to execute any Guile program _within_ the GUSH
> process.  SCSH [2] is similar to that, and there's also a Guile port [3]
> (not sure whether this is the last version).
> 
> Hope this helps,
> Ludovic.
> 
> [0] https://gna.org/projects/guile-debugging
> [1] Jonathan Rees, "A Security Kernel Based on the Lambda-Calculus",
>     http://mumble.net/~jar/pubs/secureos/ --- a enlightening paper.
> [2] http://scsh.net/
> [3] http://arglist.com/guile/


Thanks again,
Regards.


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

Re: Guile Interpreter as a Standalone Server

[Neil Jerram]

Volkan YAZICI <yazicivo@ttnet.net.tr> writes:

> Hi,
>
> I need such a feature:
>
>   /*
>    * If there's an already running guile process in the background,
>    * return it, otherwise create a new one and return new process.
>    */
>   interp = guile_interp(...);

I appreciate that Ludovic has already replied to you about this, but I
thought I'd some more thoughts.

I think the core of this idea is pretty simple to implement, and I've
appended a basic (and untested!) implementation of the server below.
After the basics, however, I think you would quickly run into
practical problems that are more tricky, such as whether you really
want an eval from one client to affect global data for another one;
what to do about error handling; what to do if an evaluation hangs;
whether you want to constrain evaluations so that they take place in a
"safe" environment; and so on.

In my view, addressing all of these things carefully would make for an
interesting project.

> With such a functionality, it'd be possible to
>
>  - Parse & execute faster. (We won't need to create a new process
>    everytime.)

Is this for a specific application, out of interest?

>  - Cache parse plans.

I don't understand what this item means.

>  - Use global variables that's accessible by any process using the
>    same interpreter.

Yes - assuming that that is a desirable feature, in general.

> Is such a feature already supported by Guile? Can I achieve above 3
> functionalities with using another method?

This doesn't feel to me like something that needs to be supported by
core Guile; it feels like a useful application that can be built on
top of Guile.

Regards,
     Neil



(let loop ((server (let ((s (socket PF_INET SOCK_STREAM 0)))
		     (setsockopt s SOL_SOCKET SO_REUSEADDR 1)
		     (bind s AF_INET INADDR_ANY port)
		     (listen s 5)
		     s))
	   (clients '())
	   (readable '()))
  (if (null? readable)
      ;; Do a new select.
      (loop server clients (car (select (cons server clients) '() '())))
      ;; Handle next readable socket.
      (let ((s (car readable)))
	(if (eq? s server)
	    ;; Accept new connection.
	    (loop server (cons (car (accept s)) clients) (cdr readable))
	    ;; Read from existing connection.
	    (let ((x (read s)))
	      (if (eof-object? x)
		  ;; Connection closed.
		  (loop server (delq s clients) (cdr readable))
		  ;; New form to evaluate.
		  (begin
		    (write (eval x (current-module)) s)
		    (loop server clients (cdr readable)))))))))



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

Re: Guile Interpreter as a Standalone Server

[Volkan YAZICI]

Hi,

On Oct 20 09:45, Neil Jerram wrote:
> Volkan YAZICI <yazicivo@ttnet.net.tr> writes:
> >  - Parse & execute faster. (We won't need to create a new process
> >    everytime.)
> 
> Is this for a specific application, out of interest?

Yes, it's for PL/scheme. [http://plscheme.projects.postgresql.org/]

> >  - Cache parse plans.
> 
> I don't understand what this item means.

You know, there're some procedure volatility levels in SQL. For
instance, non-volatile (mmiutable) procedures always return same result
as long as you supply same argument values. (Yes, we've caching for this
in PL/scheme.) For volatile procedures, result depends on lots of
outsource data, therefore its result is undeterminable. But, I had
thought that at least I can make PL/scheme perform better by just
executing the previously cached parse plan (by skipping parsing from
scracth phase) parameters) of a volatile procedure called with exactly
the same arguments.


Regards.


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