freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- From: Alex Kiesel <alex.kiesel AT document-root.de>
- To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
- Subject: RE: [freetds] goodread... not so fine
- Date: Mon, 19 Jan 2004 23:58:38 +0100
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):
"[...] 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] goodread... not so fine,
ZIGLIO, Frediano, VF-IT, 01/14/2004
- Re: [freetds] goodread... not so fine, Alex Kiesel, 01/14/2004
- <Possible follow-up(s)>
-
RE: [freetds] goodread... not so fine,
ZIGLIO, Frediano, VF-IT, 01/16/2004
- RE: [freetds] goodread... not so fine, Alex Kiesel, 01/18/2004
-
RE: [freetds] goodread... not so fine,
ZIGLIO, Frediano, VF-IT, 01/19/2004
-
RE: [freetds] goodread... not so fine,
Alex Kiesel, 01/19/2004
-
RE: [freetds] goodread... not so fine,
Alex Kiesel, 01/19/2004
-
RE: [freetds] goodread... not so fine,
Peter Deacon, 01/20/2004
-
RE: [freetds] goodread... not so fine,
Alex Kiesel, 01/20/2004
- RE: [freetds] goodread... not so fine, Peter Deacon, 01/20/2004
-
RE: [freetds] goodread... not so fine,
Alex Kiesel, 01/20/2004
-
RE: [freetds] goodread... not so fine,
Peter Deacon, 01/20/2004
-
RE: [freetds] goodread... not so fine,
Alex Kiesel, 01/26/2004
- RE: [freetds] goodread... not so fine, Alex Kiesel, 01/26/2004
-
RE: [freetds] goodread... not so fine,
Alex Kiesel, 01/19/2004
- RE: [freetds] goodread... not so fine, Alex Kiesel, 01/19/2004
-
RE: [freetds] goodread... not so fine,
Alex Kiesel, 01/19/2004
-
RE: [freetds] goodread... not so fine,
ZIGLIO, Frediano, VF-IT, 01/26/2004
- RE: [freetds] goodread... not so fine, Alex Kiesel, 01/26/2004
- RE: [freetds] goodread... not so fine, ZIGLIO, Frediano, VF-IT, 01/26/2004
Archive powered by MHonArc 2.6.24.