axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] Sockets, threads and GUI<->Kernel communication


From: C Y
Subject: [Axiom-developer] Sockets, threads and GUI<->Kernel communication
Date: Wed, 11 Apr 2007 22:24:43 -0700 (PDT)

I looked around and asked on #lisp (thank y'all on #lisp for correcting
my ignorance about such basic matters).  The upshot appears to be that
sockets are sufficiently useful to be worth dealing with the firewall
issues.  This page was mentioned as a useful introduction to the
options available: 
http://en.wikipedia.org/wiki/Inter-process_communication  A couple of
the general protocols have lisp implementations (CORBA: 
http://clorb.sourceforge.net/ and XML-RPC: 
http://common-lisp.net/project/s-xml-rpc/) but as far as I can tell
both involve MORE overhead than sockets, not less.  A real local
alternative to sockets for inter-process communication would probably
need to involve pipes or file operations, either one of which I would
worry about for portability.  I would disagree with the
characterization of socket use in Axiom as over-engineering - I think
the client-server setup adds useful flexibility, and sockets appear to
be the Right Way to implement it.

I do agree that threads are a more attractive way to implement the
client-server setup when dealing with a strictly local copy of Axiom,
and they might be more available than I previously thought.  The
closest thing to useful information I have dug up thus far are these
sites:

http://common-lisp.net/project/bordeaux-threads/
http://wiki.alu.org/Portable_Threads

While I don't know how current or comprehensive the information there
is (SBCL's support status has recently changed, according to nyef on
#lisp), they do suggest thread support might be fairly widely available
in some form.  Of course, that still doesn't help us with GCL...

I would say the thing to do is this:

Allow Axiom to have both local and remote interface clients.  The
default would be a local client, with remote connections being handled
as options.  The flow would be something like this:

1)  User starts Axiom client, default settings.
2)  Client checks for thread support.
    a.  If available, start new thread with kernel
    b.  If not available, start new process with kernel on default
socket.
3)  If process is available in in-image thread, use local calls for IO.
 If not, send them over the socket.  This should be abstracted and be
simply a matter of defining a few settings/variables.

To handle the issue of firewall interaction, I would suggest
investigating if the NSIS installer can prompt the user to add the
Axiom client and server programs to the Windows Firewall allowed list,
and perhaps open the needed port as well.  I'm not sure if this
functionality is defined there currently but it might be worth
suggesting, as I doubt Axiom and Maxima would be the only open source
programs to confront this issue.  It would also be a good idea to make
sure our error messages are informative in the case of failure to
connect, and provide all available information for resolving the
issues.

Cheers,
CY


       
____________________________________________________________________________________
Now that's room service!  Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
http://farechase.yahoo.com/promo-generic-14795097




reply via email to

[Prev in Thread] Current Thread [Next in Thread]