[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] Re: [Gcl-devel] Re: Server sockets with GCL?
From: |
Chris Hall |
Subject: |
[Axiom-developer] Re: [Gcl-devel] Re: Server sockets with GCL? |
Date: |
Fri, 07 May 2004 06:41:49 -1000 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) |
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