[freetds] goodread... not so fine
peterd at iea-software.com
Tue Jan 20 02:06:56 EST 2004
On Mon, 19 Jan 2004, Alex Kiesel wrote:
> On Mon, 2004-01-19 at 12:29, Alex Kiesel wrote:
> > > No, it's a bad design here. goodread is a low level function and should not use state (it's not expected to have knowledge of TDS state). You already added code to check TDS_IDLE however or state get set in tds_process_result_tokens or state is not TDS_IDLE (nor TDS_DEAD)...
> > > I don't think sqsh be a multi-thread application... or perhaps it use alarm() and issue cancel inside alarm signal ??
> > Sqsh is not a multithreaded application, but it indeed issues a cancel
> > within the signal handler. It does two thing from within this handler:
> > * send a cancel
> > * set a global variable which gets checked in all normal 'result
> > processing loops'. Those loops are left when this variable is set to
> > '1'. One excerpt:
> I've found some possibly interesting sections on ct_cancel in Sybase
> Client Library/C Reference Manual (page 323):
Hmm, I havn't been following this thread... but everytime the select times
out (1 second) it hits the return and bails which isn't good :(
You can reproduce by writing a query that will take a while to execute
before starting to return results. WAITFOR would pry work too.
>From there the outside switch returns marker 0, which leads to an error
and a disconnect. From the comment I don't get what goodread has to do
with infinite loops anyway. Seems like a protocol/state problem that has
to be fixed, not goodread?
> "[...] The difference between CS_CANCEL_ALL and CS_CANCEL_ATTN is:
> * CS_CANCEL_ALL causes Client-Library to discard the canceled commands
> results immediately.
> * CS_CANCEL_ATTN causes Client-Library to wait until the application
> attempts to read from the server before discarding the results.
> This difference is important because Client-Library must read from the
> result stream to discard results, and it is not always safe to read from
> the result stream.
> It is not safe to read from the result stream from within callbacks or
> interrupt handlers, or when an asynchronous routine is pending. It is
> safe to read from the result stream anytime an application is running in
> its mainline code, except when an asynchronous operation is pending.
> Use CS_CANCEL_ATTN from within callbacks or interrupt handlers or when
> an asynchronous operation is pending. Use CS_CANCEL_ALL in mainline
> code, except when an asynchronous operation is pending.[...]"
> Especially the last paragraph describes a behaviour which is not same
> same with FreeTDS. When calling ct_cancel() - no matter with what
> type-parameter - results are always read. We have seen sqsh calling
> ct_cancel() while being in an interrupt handler.
> I think we need to reproduce this behaviour to get the cancelling done.
> What do you think?
> FreeTDS mailing list
> FreeTDS at lists.ibiblio.org
More information about the FreeTDS