Skip to Content.
Sympa Menu

freetds - Re: Which API for event-driven interfaces?

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT ais.org>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: Which API for event-driven interfaces?
  • Date: Fri, 16 Nov 2001 08:05:20 -0500 (EST)


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.





Archive powered by MHonArc 2.6.24.

Top of Page