On 23/01/2010 11:52 PM, Alessandro Agosto wrote:
Hi,
i'm a python/c developer and i need an asynchronous (python) interface
to communicate with a database. I like PostgreSQL so i'm trying to write
a mock-up for a python extension module to use LibPQ in my asynchronous
programs.
What's wrong with psycopg2 for this purpose?
Python's threading support (in the standard CPython interpreter) is
awful due to the global interpreter lock. However, it works for waiting
on blocking sockets as the GIL is released before entering most
C-language routines. So you should be able to use psycopg2 in dedicated
I/O worker threads just fine.
If you're trying to use non-blocking sockets and select(...) with libpq,
well, _then_ you'll have to go outside psycopg2. Be aware, though, that
using SSL sockets in a non-blocking manner can be ... complicated ... so
look into that in detail before deciding on this path. Multiple threads
with blocking connections is likely to be a LOT easier.
Frankly, though, you're never going to get wonderful results out of
this. Twisted tries, but you've probably seen the issues it has working
around the GIL and the limited success it has doing so. CPython's GIL
dooms it to be a pretty shoddy language for high concurrency use,
whether you use an async socket server model or a blocking threaded model.
Can someone tell me what i wrong? And if you know some resource that
explains with an example how i should to verify the connection during
the select/poll, would be appreciated.
You can't reliably verify that a connection is alive with select/poll.
TCP/IP timeouts are very long and until the connection times out at the
TCP/IP level, it might appear fine even though the peer died hours ago.
--
Craig Ringer
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
