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

[Michael Koehne]

Moin Camm Maguire,

> 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.

  I would prefer to follow clisp in terms of functionality, so that one
  could play both kind of musik, instead of folling a commercial Lisp.

>    Presumably this is
>    because they count on the user relying on threads for their
>    multitasking.

  clisp is not (yet) multithreaded. So one could either use bind and
  accept to loop over listen and, or use fork to spawn a process.

>    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.  

  signals are EVIL, as they may interfer anywhere. Making GCL signal
  save, is a real big can of worms, as it will touch every system call
  in gcl/o/*.d and perhaps other sources. The best thing a GCL program
  could do after fork is to ignore the sigchild.

>    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?  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?

  i would say - lets offer the same (or comparable) low level functions
  as clisp does, and improve the high end on Lisp level. Ideas could be
  to have scheduler to implement elisp like client socket handling, to 
  migrate lots of elisp sniplets to gcl and clisp. I have a small CLOS
  class for clisp to provide a multi user interface from a MUD client,
  within only 175 lines of Lisp.

> 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?

  *oups* where ? what do you mean ? pointer to .d or .lsp file ?

Bye Michael
-- 
  mailto:address@hidden             UNA:+.? 'CED+2+:::Linux:2.4.22'UNZ+1'
  http://www.xml-edifact.org/           CETERUM CENSEO WINDOWS ESSE DELENDAM