Hi All, 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 scalability. 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 > called). > > > 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 > continues > (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 > socket > (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. > > Cheers, > - Alex > -- > UNSUBSCRIBE: mailto:[EMAIL PROTECTED] > -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]