[Openmcl-devel] Faceless Background Server Behavior

[Gary Byers]

On Thu, 9 Jan 2003, Sven Van Caekenberghe wrote:

>
> On Wednesday, January 8, 2003, at 08:46 PM, Gary Byers wrote:
>
> > I think that there's probably a bug if the listener process is actually
> > trying to read from a (detached) tty; I'll try to look into that.
>
> OK

The prelimary indication is that #_select indicates that an "exceptional
condition" exists on file descriptor 0; the lisp indicates this return
value as an indication that that file descriptor is ready for reading.

It's probably not too hard to distinguish between those cases, but
it's not clear what a REPL should do if its input stream is in an
unusable state; perhaps it should note that fact and wait until the
stream's usable, perhaps it should just exit.

In this particular case - when the lisp is in the background and has
lost access to the tty - calling #_read blocks (I'd guess that it also
generates a "tty not available" signal, but this seems to be sent to
the parent process if I read the ktrace output correctly.)  Blocking
in #_read in 0.13 prevents other cooperative threads from running,
so that's one of the worst things that can happen there.

(Well, I'm sure that we can all think of worse things ...)

>
> It is indeed much more logical NOT to enter a REPL when starting a
> faceless background server (as I already found out myself). But other
> server software like portable allegro server' start function also
> spawns a new process - so it would run in the same problem when used
> the same way.
>
> BTW, save-application is not really documented I think: it is a very
> usefull feature, but older mcl documentation probably won't help much
> since this is a quite implementation specific feature ?

IIRC, OpenMCL's SAVE-APPLICATION implements a subset of the options
that MCL's does.  (If that's true, it doesn't help anyone who doesn't
have an MCL manual handy.)

There's a related notion of the "application class" and its
distinguished instance CCL:*APPLICATION* that could stand some fleshing
out, cleaning up, and documentation.


>
> I once read on Franz' site that they can have a remote REPL to monitor,
> debug and upgrade running servers - I think that is VERY cool and will
> try to do something like that openmcl.
>
> Sven

A year or so ago I started working on a telnet server for OpenMCL.
It worked up to a point: you could start it up, then telnet to a
specified port (on the loopback interface, by default) and get a
listener.  Some things didn't work right (e.g., the pty on one
end or the other needed to set echoing options better than it did)
but enough telnet options were parsed (and often ignored) to make
it barely usable.

There were problems if too much data was sent in either direction;
I later read the right man page and found that tty/pty devices generally
have difficulty sending and receiving more than a few hundred bytes
at a time (there's a way to find out exactly what the limit is.)  I
got stumped by that and stopped working on it; I've meant to go back
to it, but haven't had the time.

The Cocoa demo (which uses pty's in its listeners) knows how to
overcome the buffer-size limitations (by using smaller buffers on
the lisp side and/or putting the file descriptor into non-blocking
mode.)   I'm not sure if that code would be a useful starting point
or if it'd be easier to start from scratch; if anyone's interested
in that code (which'd probably need some changes to work even as
well as it did), let me know.

A full-blown telnet server would certainly be useful (as would
a minimalist one which just told the client "NO" during option
negotiation.)



_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel