FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

Hmmmm....

On Fri, 16 Nov 2001, James Cameron wrote:

> When programming event driven GUIs such as GTK+, programmers generally
> avoid threads and prefer the underlying APIs to support an event driven
> model; submit a query, wait for file descriptor to be readable using
> select().
> 
> Of the interfaces provided in FreeTDS, which of them are appropriate?
> 
> Requirements:

> - can submit query separate to obtaining result set,
No problem, just use dbsqlsend() for dblib or ct_send() for ctlib 
(dbsqlexec() is blocking)

> - exposes a file descriptor of a socket on which data is to arrive,
file descriptor for the socket can be obtained via dbproc->tds_socket->s 
or cmd->con->tds_socket->s for ctlib.  These are non-portable options 
however. There are certain asynchronous behaviours in both APIs (the _a 
functions in dblib and certain argument passing in ctlib), however they 
are largely unimplemented (aka, no ones every asked before).

> - can know for certain when a query is complete.
You can use the above to know when data is first available. Not the same 
thing exactly. FreeTDS will block upon finishing reading one packet and 
reading the next (see src/tds/read.c for details), however once data 
starts appearing it generally gets sent with much delay.  The greatest 
possible "out to lunch" behaviour comes between sending the query and the 
data server beginning to send results.