Re: What's next?

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.

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

On Thu, Aug 18, 2011 at 9:57 AM,  <[email protected]> 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
> [email protected]
> http://lists.ibiblio.org/mailman/listinfo/freetds
>