Skip to Content.
Sympa Menu

freetds - Re: [freetds] 0.64 status and coverage

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Peter Deacon <peterd AT iea-software.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] 0.64 status and coverage
  • Date: Thu, 14 Jul 2005 13:15:42 -0700 (Pacific Daylight Time)

On Thu, 14 Jul 2005, Frediano Ziglio wrote:

I know however it's a nice feature to have and easy to implement.
In early days there where an executable linked to some few libraries
(like libc) but nowadays in context like

<- PHP <- php_mssql.so <-
httpd (Apache) <- Python <- ???.so <- libdblib.so
<- mod_perl <- DBD::DBLib <-

is difficult to define who should call dbexit... you end up in
situations where the better way is to call only dbinit... I got the same
problem with socket and windows. Under windows you have to initialize
socket library with WSAStartup, use sockets and then you should call
WSACleanup. However after WSACleanup you cannot call any socket API. In
3 cases (OCX used in an ASP page, ISAPI and an extended store procedure
in mssql) I decided to NOT call WSACleanup to prevent main program
(respectively IIS, IIS and mssql) to stop working correctly (in IIS case
I decided to not call WSAStartup too...). Now in FreeTDS you can call
safety dbinit/dbexit, just call dbinit and dbexit once.

FWIW WSAStartup/Cleanup and most routines that I know of that behave in the same way use internal reference counts to prevent problems like the above from occuring. You just need to make sure that you call init the same number of times you can cleanup. Only the last call to cleanup actually does anything.

Have Fun!
Peter




Archive powered by MHonArc 2.6.24.

Top of Page