Skip to Content.
Sympa Menu

freetds - RE: [freetds] goodread... not so fine

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] goodread... not so fine
  • Date: Mon, 26 Jan 2004 12:16:26 +0100

>
> On Mon, 2004-01-19 at 12:29, Alex Kiesel wrote:
> > 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:
>
> Hi all,
>
> I've written a patch, which should fix FreeTDS cancel behaviour in
> ctlib.
> The problem has indeed been in reading from / writing to the
> wire while
> within an interrupt handler. When remodelling Sybase behaviour more
> exact, that is, waiting for the next "normal access" to the data and
> just then executing the cancellation, it seems to work fine.
>
> After having a (short) look at dblib and odbc, I've come to the
> conclusion that the problem is a pure ctlib problem and thus should be
> fixed in ct.c, not in the tds layer:
> * dblib does not have an asynchronous cancel (or am I wrong here)
> * ODBC must handle multithreaded applications in SQLCancel which is
> something completely different as what ctlib has to do.
>
> Next to my patch, I'm sending a unittest for ctlib (t0010.c), which
> simulates what I did manually with sqsh.
>
> Could someone have a look at it, please?
>

I do not agree with this patch that much... client should send cancel.
If server want to return thousand rows is good to stop it. Also
ct_retults should return CS_CANCELLED, not CS_FAIL on cancelling. ODBC
is not completely different. On SQLCancel it should send cancellation,
all current operations should return failure with state cancelling then
SQLCancel should handle cancellation, the only difference I see is who
should handle cancellation... It's not easy cause 2 thread works on same
data and only one should process a token at a time... so
tds_process_results should not exit before processing current token and
tds_process_cancel should not get data until tds_process_results exit...
On signal handling cancel can't wait tds_process_results (cause it's not
a thread...) however it should works too... I think we should solve both
ct_cancel and both thread handling... a cancelling state will help
tds_process_results to not handle data handled by tds_process_cancel
however it do not helps tds_process_cancel to not handle
tds_process_results data... Perhaps a state that tell some thread is
processing data?

So will have:

TDS_IDLE -> tds_submit_*() -> TDS_QUERYING -> TDS_PENDING ->
tds_process_results() -> TDS_PROCESSING -> handle data -> TDS_PENDING ->
test cancel/dead -> tds_send_cancel() -> send cancel on
TDS_PENDING/TDS_PROCESSING wait for TDS_PENDING -> TDS_CANCELLING ??
To solve thread problems I'd add pthread_mutex_* and attempt to set/test
state inside a mutex... IMHO all Unix systems should support mutexes...
If anyone know good automake tests/library that support thread...

freddy77




Archive powered by MHonArc 2.6.24.

Top of Page