Skip to Content.
Sympa Menu

freetds - Re: [freetds] What's next?

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Frediano Ziglio <freddy77 AT gmail.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] What's next?
  • Date: Thu, 18 Aug 2011 17:12:25 +0200

2011/8/18 Brian Bruns <brian AT bruns.com>:
> Hi Jim,
>
> I need to send a read/write request off to the server receive an
> EAGAIN and then go about my business and do a big select() with both
> the tds socket and other file descriptors and come back when there is
> something to handle.  I need to never, ever wait for the network.
>
> I have a working mock-up against 0.82, but am currently forward
> porting to 0.91 (boy, there were some changes).  Basically, my
> approach is to have a tds->async flag that controls whether we use
> async or blocking (well, select, recv/send, technically non-blocking
> but besides timeouts, what's the point).  All the packet stuff (buf,
> buf_max, len, pos) moves to a TDSPACKET structure and is a list
> instead (since the PDUs can span packets, list size only > 1 if using
> async mode).  Even if you could set a zero timeout with the current
> code, the second the processing code runs off the end of the packet
> you are doing a network wait for the next packet, no way to rewind
> processing and restart that token once you have more data.  It doesn't
> currently work with SSL/TLS but cross that bridge later.
>

I have a TDSPACKET in MARS patch too :)

> It's surprisingly not a terribly intrusive patch, but would allow for
> supporting ctlib asynchronous stuff (ct_poll and friends) and
> presumably SQL_ATTR_ASYNC_ENABLE in ODBC though I can't speak
> authoritatively on that.
>
> Brian
>

I never used async in ODBC...

> On Thu, Aug 18, 2011 at 9:57 AM,  <jklowden AT schemamania.org> wrote:
>> On Thu, Aug 18, 2011 at 07:07:01AM -0400, Brian Bruns wrote:
>>> I'm working up a patch to support asynchronous I/O.  So far it's just
>>> at the libtds level, but its a start.
>>
>> Brian, I consider server I/O a solved problem.  We use non-blocking I/O
>> (FIONBIO), and support timeouts and interrupt processing with 1-second
>> granularity.  What problem are encountering that you'd want to use
>> asynchronous
>> I/O for instead?
>>
>> --jkl
>> _______________________________________________
>> 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
>




Archive powered by MHonArc 2.6.24.

Top of Page