What does this have to with lib/apr-signal.c???? Come on guys, change the subject if you're changing the topic...
david > On Thu, Jul 12, 2001 at 12:47:13PM +0200, Sander Striker wrote: > > [...] > > > what i suspect is happening in subversion [correct me if i'm > > > wrong, here!] is that they are writing their own server-code. > > > > You're wrong :) > > wha-heeey :) i like being wrong :) > > > subversion is going to use httpd with mod_dav as the server :) > > ... *enthusiastic*... omigud, i'm 25% way through mod_dav.c when > i looked at the LOC good _grief_. okay, that's irrelevent. > > i get the idea. > > > Wondering what the framework like socketserver.py looks like. > > Summary? > > SocketServer.py is basically three sets of classes [with > specialisations of each] that you then 'mix' together to > get the required combination for your server. > > set one: > > BaseServer. specialisations: TCPServer and UDPServer > [i wrote a SQLTableReadingServer > where the 'request' is the data > _read_ from a queueing-table!] > > Mixin. specialisations: ForkingMixIn and ThreadingMixIn. > [on the TODO list is a single-process > Mixin that keeps a list of all connections > *itself* and has to deal with them one-by-one > with all the associated blocking and select > problems etc. on a series of file descriptors] > > Handlers. basically this allows you to 'Do' things to a > request. there are some pre-defined UDP and TCP request-handling > classes that you still have to over-ride functions to actually > _do_ something with the request socket, but at least it _gives_ > you a per-connection socket. > > the SocketServer framework basically provides a common API to > create, handle, finish and close requests. you don't have > to worry about how the request gets _to_ you: you only > have to provide methods to deal _with_ the request. > > so you combine the above classes to get: > > ThreadingUDPServer > ThreadingTCPServer > ForkingUDPServer > ForkingTCPServer > > and, with the addition of BaseServer, i created > ForkingSQLTableReadingServer, which polls [yes, i know] > a SQL table, locks it, reads one entry, deletes it from > the table, unlocks the table, > creates a handler for it, passes the entry to the > handler, the handler Does Its Thing (in this case, > loads from a SQL table a python script named in the > request and runs it!) > > now, whilst this level of genericity is probably excessive, > it was trivial to do, and it also provides the means to > *transparently* add... mmmm.... SSLServer and then > mix it in with Forking and Threading and you change *zero* > lines of code - ssl is all done for you. > > redirection. loop-back testing. unix-domain-socket server. > even a TransactNamedPipe server - whatever you can dream up. > > > > It seems that the apache server framework can be extended > > with other protocols by just adding new modules and filters. > > ... what if people don't want to add new modules and new filters? > > what if they want to go a separate route but take advantages > of the best bits of httpd's code, and share the results? > > :) > > luke >
