Skip to Content.
Sympa Menu

freetds - RE: [freetds] tdsdump SIGSEGV with mt apps

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] tdsdump SIGSEGV with mt apps
  • Date: Fri, 6 May 2005 10:32:51 +0200

>
> Hi,
>
> Attached is my patch which from my testing, appears to fix
> the timeout
> problems, makes dblib and TDSDUMP thread-safe.
>
> I've had to modify the ODBC test case in order for it to pass. I
> believe this is the appropriate behaviour for the test case but I
> could be mistaken.
>
> Comments?
>
> Thanks.
>

Well... this patch contain many different change that need some
adjustement
- pthread support. It add a tdsthread.h header that support pthread for
mutex only. It need some support to check for pthread in configure. I'm
not sure if tds_sysdep_private.h is a better place for this stuff.
- timeout. New timeout in TDSSOCKET. I'm very again this. There are
already a query_timeout, timeout name looks quite weird. You said that
this timeout is a network timeout (timeout on network wait). So perhaps
call it network_timeout. However upper layer do not support "network
timeout" concept but only "query timeout" so the only way to set this
timeout is in freetds.conf. What action should we take for this timeout?
We have 3 action:
1- continue, that is ignore timeout, discarded
2- exit, I don't like this action
3- cancellation, this is the only resonable action whoever application
will receive a cancel error without requiring a cancel... is it
expected? Isn't query_timeout sufficient?
I think this change should be open for discussion. Timeout is already
too complicated and seems to not work as expected... honestly I always
intended "timeout" configuration (in freetds.conf) as query_timeout. I'm
committing a path in CVS that will add a "query timeout" option that is
just an alias of "timeout", I hope to remove the ambiguity (updating UG
advising anyone to use "query timeout" instead of "timeout"). This
require a good test on dblib.
- timeout odbc test. It works however as you spot it should not call
ODBC_REPORT_ERROR after Disconnectiong.. I'll commit a fix ASAP
- dump serialization using thread. I'll commit it ASAP
- goodread rewriting. It still do not support interrupting and add an
extra 60 seconds polling on connection. I'll look deeper...
- dblib threading... sorry but I'm still again the big lock around
tds_ctx... the problem seems only dbexit so I still think that tds_ctx
don't suffer thread problems...

I'll update your patch and send an updated version on ML.

freddy77




Archive powered by MHonArc 2.6.24.

Top of Page