Hi Konrad,

> Are their any existing picoLisp functions for using the select system
> call and doing asynchronous IO

Yes. In fact, this is the basis of almost all activities in a typical

The main control structure is a list of file descriptors and expressions
in the global '*Run', usually in combination with the interface function

For example, if you want to listen on multiple ports:

   (for P (4001 4002 4003 4004)
      (task (port P)
         (when (accept @)
            (task @
               Sock @
               (in Sock
                  (if (rd)
                     (out Sock (eval @))
                     (task Sock)
                     (close Sock) ) ) ) ) ) )

This will listen on those four ports, and whenever a connection request
arrives, it will install a new task on this socket. Then, whenever data
arrive on that socket, they are taken as an 'exe' expression, and get
evaluated with the current output channel set to that socket. If EOF
arrives instead, the connection is closed and the task un-installed.

This happens all in the "background". You may still have some main loop
in your program (or, if not, you will be dropped into the console ':'
prompt). The "do nothing" main loop, BTW, is (wait), that's why the
examples for applications often have a '-wait' on the command line.

There are endless ways to combine 'task' with I/O functions. A simple
"single shot" background task, accepting a request on port 4444, reading
an expression, evaluating it and immediately closing the connection:

   (task (port 4444)
      (let? Sock (accept @)
         (in Sock (out Sock (eval (rd))))
         (close Sock) ) )

Or, a main loop keeping multiple connections open on port 4444:

   (setq P (port 4444))
      (task (listen P)
         (in (setq Sock @)
            (if (rd)
               (out Sock (eval @))
               (task Sock)
               (close Sock) ) ) ) )

> for anyone curious I find myself desiring an asyncronous http server.
> rather than the current forking server. This I know is not currently

I preferred a forking server simply because it makes it easier to keep
the state and context for each client.

> present (in fact the server in http.l seems to be very strongly tied
> to the gui framework, and hence makes a lot of assumptions that I want

I do not feel that "lib/http.l" is tied to the 'xhtml' and 'form' parts.
Originally, I developed it for the Java GUI (the "lib/gui.l" and
"lib/gui2.l" files, no longer in the standard release). You just should
not use the 'server' function from "lib/http.l", but write something
along the lines of the above examples.

- Alex

Reply via email to