[Axiom-developer] Re: [Gcl-devel] Re: Server sockets with GCL?

[Chris Hall]

Camm Maguire <address@hidden> writes:

> Greetings!
>
> A few observations regarding sockets in GCL:
>
> 1) There appears to be hooks in the current code for functions which
>    were later removed, perhaps as a result of the KCL->GCL migration.
>    Look at nsocket.c for the commented out empty function update,
>    etc.   

Yup, saw those, and wondered what led to their 'inactivation'.

>
> 2) From what I can tell, the server function passed to si::socket is
>    therefore not currently used.  I've checked all the references to
>    object0->c.c... and unless I've missed something, this
>    functionality has been removed.

Eeep!  I think I started looking at that, got distracted, and then
forgot all about it.  Doh.

>
...
>
> 4) Fixing this is not hard -- its just that it is not clear what is
>    best to do.  As we all know, there is no socket standard in the
>    ANSI spec.  It has been expressed that compatibility with allegro
>    would be desirable, at least for SLIME, but there appears to be no
>    multiplexing ability in their implementation.  Presumably this is
>    because they count on the user relying on threads for their
>    multitasking.  The dominant socket server paradigm of which I am
>    aware is 1) bind 2) listen 3) accept 4) fork/spawn, whatever on the
>    new socket.  This would be simple to implement in GCL via fork()
>    (no Windows), but this would mean running one image per connection,
>    which is quite a lot of memory.  Threads reduce this hurdle, but
>    they are much harder in lisp, where one has to worry about the GC.
>    We won't be able to do that any time soon, at least without some
>    detailed pointers/examples of other treatments.  So this might
>    indicate that either 1) a multiplexing based on select() or 2) a
>    SIGIO based multitasking system might be preferable.  I've had a
>    bit of trouble with SIGIO signal handlers restarting some system
>    calls on exit in the past -- don't know if this is a permanent
>    problem.  

As I mentioned in a related thread, I would like to (humbly) suggest the
select() option - for your reasons here and others mentioned in my
related post.

>
>    Presumably one does want to assign some function to handle the i/o
>    on the socket *in the background* while returning control to the
>    user, no?

If we go the select() route, couldn't we use a defstruct/plist/object to
hold functions to be called for the various events (data_available,
connection_lost, etc.)?  This defstruct/plist/object would be returned
from/created by the function creating the associated socket.

As I understand select(), one uses an associated map of fd's for it to
monitor - with just a wee bit of abstraction, mightn't it be possible to
have it use a map of socket defstructs/plist/objects?

I'll come clean - a lot of my ideas are cribbed from the Python standard
lib 'asyncore'.  A brief API description is available at:

http://www.python.org/doc/current/lib/module-asyncore.html

>               Would it not also be preferable to have some sort of
>    attach/detach procedure like in gdb to connect and disconnect from
>    a running process?

Yes!  Then wouldn't we be able to get a REPL perhaps as well?

>
>    BTW, noticed on allegro's site that SSL is only supported in
>    Enterprise versions.  I've written my own ssl socket multiplexer
>    (non-server) in C, which in principle is easily integratable into
>    GCL if an interface can be decided upon, using openssl, so maybe
>    this would be attractive.

I think in today's networking world, it would be very attractive.  It
might even put GCL one up against the other Lisps. ;-)

>
> 5) Speaking of fork(), I just noticed that we are not even compiling
>    in run-process and the like, at least on linux.  Does anyone want
>    this back?

Sounds good to me. :-D

Aloha,
+Chris 

-- 
We hang the petty thieves and appoint the great ones to public office.
-- Aesop (620 BC - 560 BC)

pgpImTzOKUiZo.pgp
Description: PGP signature