FreeTDS Development Group

[Brian Bruns <brian AT bruns.com>]

Erm, I should have been clearer.  I'm using asynchronous I/O in a more
generic sense, my implementation is using standard non-blocking I/O as
the underlying mechanism.  I think ctlib calls this "deferred mode" or
some such.  If we shot for full ctlib asynchronous implementation we'd
have to do signaling too.  Oh god, I wouldn't want to have to handle
SIGIO all over the place.  I'll leave that in the maybe-someday
bucket, not my immediate concern.

I am using a small wrapper to interface directly to libtds, even if I
have advised everyone would ever came on this list from doing exactly
that.  I wouldn't mind using ctlib or ODBC, but that is a whole other
layer to add support to and I'm still struggling to get this part
right.

Brian

On Thu, Aug 18, 2011 at 3:35 PM,  <jklowden AT schemamania.org> wrote:
> On Thu, Aug 18, 2011 at 10:51:21AM -0400, Brian Bruns wrote:
>>
>> 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.
>
> Hi Brian,
>
> Stevens devotes a chapter each to non-blocking, asynch, and
> signal-driven I/O.  They're all functionally equivalent.  I think
> non-blocking is the best choice because it's the most portable.
>
> We see EAGAIN now when connecting.   We're already set to support the
> "asynchronous" client library functions; we don't need FIOASYNC to do
> that.   It's just a SMP.
>
> I wrote tds_select() to support timeouts and dbinterrupt().  It might
> be trickier than you realize, because of the callbacks to the client
> libraries and the fact that they don't deal with timeouts in the same
> way.  It took me quite a while to straighten it all out.
>
> I think what you really want is a low-level interface to libtds?
>
> It's interesting -- and no coincidence -- that you and Frediano and I
> all see need for changes in libtds.  I've been thinking about this for
> quite some time, and I have some suggestions.  Let me start a new
> thread for them, though.
>
> Regards,
>
> --jkl
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>