Skip to Content.
Sympa Menu

freetds - RE: [freetds] ctlib enhancements

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: "'freetds AT lists.ibiblio.org'" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] ctlib enhancements
  • Date: Wed, 8 Jan 2003 16:02:19 -0500

> From: ZIGLIO Frediano [mailto:Frediano.Ziglio AT vodafoneomnitel.it]
> Sent: January 8, 2003 5:47 AM
>
> > . async function, async calls (dbpoll() and friends)
>
> I think a thread should be opened for this. Even ODBC have async...

I'd rather fork(), given the ragged state of Posix threads.

To implement dbpoll(), we have to:

1. send the query
2. fork a process that will block, waiting for its result token
3. mark the tds process with the the child's pid
4. return control to the caller.

When the server responds, the child need only mark the tds process as ready
(by erasing its pid) and return.

dbsqlok(), for example, would examine the tds process structure. If it
finds a pid, it issues a wait(2); else it's ready and returns.

The overhead of fork() to spawn a process that will immediately block, mark,
and return is not that high relative to the rest of the processing. There
won't be hundreds of them because they'll have short lifetimes. And fork(),
unlike threads, has a solid implementation on every platform, except the one
that will remain unnamed.

Nes pas?

Scott Gray once told me he had begun to rewrite libtds based on a design
more like Sybase's. Now I think I begin to understand why. What's really
needed is a reader daemon that will always be reading. As packets arrive,
the appropriate process would be signalled. Instead of reading directly
from the network socket, processes would read from a pipe fed by the reader.


> > . bcp support to ctlib
>
> We should move bcp code to libtds.

That's a good idea, particularly since Microsoft's ODBC driver supports BCP,
too.

--jkl


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.






Archive powered by MHonArc 2.6.24.

Top of Page