FreeTDS Development Group

[Peter Deacon <peterd AT iea-software.com>]

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?

Have Fun!
Peter

> "[...] 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?
>
> Greets,
> -Alex
>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>