Skip to Content.
Sympa Menu

freetds - RE: [freetds] ctlib enhancements

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT ais.org>
  • To: "'freetds AT lists.ibiblio.org'" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] ctlib enhancements
  • Date: Wed, 8 Jan 2003 20:11:36 -0500 (EST)

Aren't threads and forking overkill for this. I don't know about ODBC, but
dbpoll() is basically a wrapper on select(), n'est pas?

Brian

On Wed, 8 Jan 2003, Lowden, James K wrote:

> > 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.
>
>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>





Archive powered by MHonArc 2.6.24.

Top of Page