In the matter of how to begin. Twisted is I think the wrong place. It
is a very large and complicated beast which has grown in its own
unquie direction. So much so that it is incompatable with a lot of
standard python tools and libraries, uses its own logging system etc.
In copying python the place to start are Asyncore and Asynchat. The
Medusa pages had some basic examples of building an asyncronous client
and then an asyncronous proxy.
I intend to try to build these things and satisfy myself that I'm
really getting asyncronous behaviour.
After that I'm thinking that a good proof of concept application would
be a basic instant messanger which allows multiple users to connect
and send messages to each other. this is a nice application which has
shared state without needing a particularly fancy interface.
As this is a personal project, I'm happy to share code, questions and
comments through this list if there is interest.
A similer Tic Tac Toe server which allows multiple simultainous games
and routes moves to the correct clients would also be nice.
Then its on to the main event. where more care is needed in working
out what functions are needed and how additional functionality should
be hooked into the system. Here I would be aiming to build a generic
UDP and TCP server that is as adaptable as Medusa and Twisted.
At this point, if there is enough interest. putting code on
Sourceforge or Google code might be worth while. Heck it might even
give pico Lisp some extra publicity. (I note this list has been
getting a little more lively lately, which is a good sign).
And can be used as a base for any protocol anyone chooses to throw at it.
One reason why the Async approach is well suited to python is due to
limitations in the Python interpreter. Python has something called a
Global interpreter lock, which restricts it to using a single CPU,
even if threading primitives are used. Ergo threading primities become
an overhead which increases code complexity without giving increased
I believe that picoLisp has similer single CPU limitation, I'm pretty
sure that there are no threading primitives. So the only possible
choices are Asyncronous or Forking. The latter makes shared state
somewhat difficult to manage, and exists allready (so there is nothing
new to build).
2008/10/9 Alexander Burger <[EMAIL PROTECTED]>:
> Hi all,
> oops, sorry! Forget what I wrote:
>> A ".html" file will
>> be directly sent to the client, without any forking. And also ".l" files
>> do not automatically cause the fork, but only if (app) is called during
>> their execution.
> This was wrong. The 'server' function in "lib/http.l" will always fork
> when a connection request arrives. It is just that the child process
> immediately terminates after serving the connection (unless (app) was
> BTW, as a matter of an example, the 'server' function in "lib/http.l"
> *does* implement a non-forking server, but only in the child process
> once the initial connect from a client has created a session:
> (loop # Main loop in the parent process
> (setq *Sock (listen P)) # Wait for a request
> (NIL (fork) (close P)) # The child closes 'P' and exits the loop
> (close *Sock) ) # The parent closes the new connection and
> (task *Sock (http @)) # The child installs a task on that socket
> (http *Sock) # and serves the first page
> (or *SesId (bye)) # If (app) was not called, terminate
> (task *Sock # Else install a task for the new session
> (when (accept *Sock) # Accept requests on that socket
> (task @ (http @)) # without forking
> (http @) ) ) )
> Note: This uses in two places a construct of the form
> (task <socket> (http <socket>))
> (http <socket>)
> The reason for that is that for HTTP/1.1 more than one transaction may
> be done before the connection is closed.
> Hope this helps.
> - Alex
> UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]