[Stackless] announcing Concurrence Framework

Bob Ippolito bob at redivi.com
Fri Jan 16 19:49:27 CET 2009


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 <andreas at kostyrka.org> wrote:
> Am Fri, 16 Jan 2009 18:00:41 +0100
> schrieb Henk Punt <henkpunt at gmail.com>:
>
> 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
>> <andreas at kostyrka.org> wrote:
>> > Am Mon, 12 Jan 2009 16:22:37 +0100
>> > schrieb "Henk Punt" <henkpunt at gmail.com>:
>> >
>> >> 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
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless
>




More information about the Stackless mailing list