James K. Lowden
jklowden at freetds.org
Thu Sep 26 21:52:31 EDT 2013
On Thu, 26 Sep 2013 17:52:02 -0700
Marc Abramowitz <msabramo at gmail.com> wrote:
> Today, a colleague and I got excited about making pymssql "green" by
> supporting "green" thread implementations like gevent by adding a
> callback to pymssql that it would call after the query has been sent
> and before the results are received. One could have this callback
> call something like gevent.sleep() to yield control to another
> What I'd really like to get do is use the dbdataready  function of
> DB-API so that I can avoid blocking on dbsqlok.
There's no plan. In case you're interested in trying, it's either
fairly simple or nearly impossible to implement.
There are only three ways to know if a TCP socket has data waiting to be
1. read(2) & friends
(There are signals, too, but they don't work well for TCP connections,
nor with threads generally. So they don't count.)
FreeTDS uses poll(2). It could maintain a flag named, say, fready. It
would clear the flag before calling poll, and set it when poll returned
with an indication that data are pending on the socket. dbpoll(),
then, would simply examine the flag.
(There is a small vendor incompatibility: Microsoft calls it
dbdataready; Sybase calls it dbpoll.)
It's a little more involved than that, because the notion of data
pending to be read consists of more than what poll(2) last reported.
The question dbpoll() answers is narrower: can dbresults be called now
without blocking? That's deep in the libtds state machine, which isn't
very clearly elucidated in the code.
The question in my mind that I can't look into right now is whether or
not there's always a read pending after a query is issued, or if
libtds begins reading only when requested to do so by the client
library. If there's always a read pending, then the putative flag
would be easy to implement. If not, it would take some work to get
dbpoll the information it needs.
More information about the FreeTDS