pg8000 is probably a better base for building a PostgreSQL binding, it's pure python. psycopg2 does wrap libpq's async functionality, but it's ugly to use.
-bob On Fri, Jan 16, 2009 at 10:42 AM, Andreas Kostyrka <[email protected]> wrote: > Am Fri, 16 Jan 2009 18:00:41 +0100 > schrieb Henk Punt <[email protected]>: > > Well, libpq (not sure about the python bindings) does support an async > select-friendly alternative API. > > Another thing, I've wondered, what's the idea with > concurrence._threading.disable_threading()? AFAICT it does nothing but > load the dummy and normal threading modules. > > Plus, I wondered why you are not trying to provide an 1:1 compatible > replacement socket module => this way, one could probably use most if > not all stdlib network protocol implementations. (They are not always > perfect implementations, but it seems like a "cheap" way to get a basic > set of protocols mostly free. > > Ah, I've started hacking around, not sure if that makes sense: > > diff --git a/lib/concurrence/io/socket.py b/lib/concurrence/io/socket.py > index c2fb488..0e1c5eb 100644 > --- a/lib/concurrence/io/socket.py > +++ b/lib/concurrence/io/socket.py > @@ -93,6 +93,19 @@ class Socket(IOStream): > > return self.__class__(s, self.STATE_CONNECTED) > > + def getpeername(self): > + return self.socket.getpeername() > + > + def getsockname(self): > + return self.socket.getsockname() > + > + def getsockopt(self, level, optname, *buflen): > + return self.socket.getsockname(level, optname, *buflen) > + > + if hasattr(socket.socket, "ioctl"): # win32 only > + def getsockopt(self, control, option): > + return self.socket.ioctl(control, option) > + > def _connect(self, addr, timeout = -1.0): > assert self.state == self.STATE_INIT, "make sure socket is not > already connected or closed" > > TIA, > > Andreas > >> You guessed right :-) >> >> Anyway, concurrence already contains a 'asynchronous' implementation >> of a driver for MySQL, >> so there is no threading issues there..., all the communication is >> handled async in the background with >> the database (it is just a tcp/socket connection afterall) so no >> threads used. high-level API is DBAPI compatible (blocking style). >> I currently use concurrence in combination with SQLAlchemy/MySQL with >> no threads and this works fine... >> >> For any other db, 2 possibilities: >> >> 1) implement async driver for given database >> 2) implement some wrapper for existing DBAPI drivers using OS-level >> threads in the background... (this is what Twisted does) >> >> On Fri, Jan 16, 2009 at 12:30 AM, Andreas Kostyrka >> <[email protected]> wrote: >> > Am Mon, 12 Jan 2009 16:22:37 +0100 >> > schrieb "Henk Punt" <[email protected]>: >> > >> >> Hi, >> >> >> >> I would like to announce the availablility of the 'Concurrence >> >> Framework'. (http://concurrence.googlecode.com) >> >> >> >> Basically it is a library build on top of Stackless that enables >> >> the easy creation of high performance network servers >> >> (http servers, chat servers, comet servers etc etc). >> >> >> >> It is similar in scope to the Twisted framework, but it uses a >> >> Lightweight-processes-with-message-passing approach to concurrency >> >> as opposed to Twisteds event-driven model. >> >> >> >> I have created this framework out of frustration with Twisteds >> >> model. After working for some years with Twisted it has become >> >> apparent to me that the event-driven model for IO/socket >> >> programming although very performant, quite easily leads to >> >> difficult to maintain program code... >> >> >> >> Instead I would prefer to program in a 'blocking' style like you >> >> would traditionally do with threads. At the same time I still >> >> would like to retain >> >> the performance and lack of threading issues of event-driven IO. >> >> >> >> This is what the Concurrence Framework provides... (trough >> >> Stackless and libevent) >> >> >> >> Most notably it already includes: >> >> - a Socket API, >> >> - a DBAPI 2.0 compatible implementation of a MySQL Driver >> >> - an implementation of a HTTP1.1/WSGI compliant webserver. >> >> >> >> Some components are implemented in Pyrex for speed (low level >> >> interface to libevent, IO buffer interface, low-level MySQL stuff). >> >> >> >> The code is currently quite usable, but some interfaces might still >> >> change as I gather feedback from the community. >> >> >> >> In the following weeks I will try to finalize the core >> >> documentation and I will create a proper website to host it. >> >> >> >> In the meantime, anyone interested can checkout the code from >> >> coogle code: >> >> >> >> svn checkout http://concurrence.googlecode.com/svn/trunk/ >> >> concurrence >> >> >> >> from there please follow the instructions in INSTALL.TXT (currently >> >> Linux/MacOSX only). >> >> >> >> Documentation can be found in doc/_build/html/index.html, but this >> >> is a work in progress... >> >> Examples used in the documentation can also be found in the >> >> examples directory. The unittests in the test directory could also >> >> provide some guidance on how to use the framework. >> >> >> >> Issues/feedback can be mailed to me or you can add an issue on >> >> http://code.google.com/p/concurrence/issues/list. >> > >> > I just noticed that there is no mailing list nor a way to contact >> > you from the google page. OTOH, perhaps the usernames displayed map >> > 1:1 to gmail.com email addresses? *wonder* >> > >> > What I wondered is, if concurrence can handle real threads too? I >> > wondered because DB connections can take quite a bit of time to >> > establish, so I wonder how you deal currently with that? >> > >> > TIA, >> > >> > Andreas >> > > > _______________________________________________ > Stackless mailing list > [email protected] > http://www.stackless.com/mailman/listinfo/stackless > _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
