Skip to Content.
Sympa Menu

freetds - RE: [freetds] ctlib enhancements

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Michael Peppler <mpeppler AT peppler.org>
  • To: freetds AT lists.ibiblio.org
  • Subject: RE: [freetds] ctlib enhancements
  • Date: 08 Jan 2003 17:40:22 -0800

On Wed, 2003-01-08 at 17:11, Brian Bruns wrote:
> 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?

Yes, I was thinking the same thing - use non-blocking IO on the socket,
and use select() to find out when something is ready to be read...

Michael


> 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
> >
>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
--
Michael Peppler Data Migrations, Inc.
mpeppler AT peppler.org http://www.mbay.net/~mpeppler
Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or
long term contract positions - http://www.mbay.net/~mpeppler/resume.html




Archive powered by MHonArc 2.6.24.

Top of Page