Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] [PATCHES] Compiling libpq with VisualC

From: "Gary Doades" <gpd(at)gpdnet(dot)co(dot)uk>
To: pgsql-hackers-win32(at)postgresql(dot)org
Subject: Re: [HACKERS] [PATCHES] Compiling libpq with VisualC
Date: 2004-06-14 17:59:34
Message-ID: 40CDF596.16134.1021004B@localhost (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-hackers-win32pgsql-patches
On 13 Jun 2004 at 19:57, Bruce Momjian wrote:

> 
> Yes, but consider that two threads could both call it, with one perhaps
> using the first value, and the second overwriting the first.  Obviously
> not something we want.
> 

Every Windows DLL has (or can have) a DllMain function. This is called 
everytime a Dll is attached to (loaded) by a process or thread. You can 
put any one-time initialisation in this function and guarantee that it is 
only called by the first process/thread that loads the dll.

BOOL WINAPI DllMain(
  HINSTANCE hinstDLL,
  DWORD fdwReason,
  LPVOID lpvReserved
);

Parameters:

hinstDLL 
[in] Handle to the DLL module. The value is the base address of the 
DLL. The HINSTANCE of a DLL is the same as the HMODULE of the 
DLL, so hinstDLL can be used in calls to functions that require a 
module handle. 

fdwReason 
[in] Indicates why the DLL entry-point function is being called. This 
parameter can be one of the following values. Value Meaning 

DLL_PROCESS_ATTACH The DLL is being loaded into the virtual 
address space of the current process as a result of the process starting 
up or as a result of a call to LoadLibrary. DLLs can use this opportunity 
to initialize any instance data or to use the TlsAlloc function to allocate 
a thread local storage (TLS) index. 

DLL_THREAD_ATTACH The current process is creating a new thread. 
When this occurs, the system calls the entry-point function of all DLLs 
currently attached to the process. The call is made in the context of the 
new thread. DLLs can use this opportunity to initialize a TLS slot for the 
thread. A thread calling the DLL entry-point function with 
DLL_PROCESS_ATTACH does not call the DLL entry-point function 
with DLL_THREAD_ATTACH. 
Note that a DLL's entry-point function is called with this value only by 
threads created after the DLL is loaded by the process. When a DLL is 
loaded using LoadLibrary, existing threads do not call the entry-point 
function of the newly loaded DLL.
 
DLL_THREAD_DETACH A thread is exiting cleanly. If the DLL has 
stored a pointer to allocated memory in a TLS slot, it should use this 
opportunity to free the memory. The system calls the entry-point 
function of all currently loaded DLLs with this value. The call is made in 
the context of the exiting thread. 

DLL_PROCESS_DETACH The DLL is being unloaded from the virtual 
address space of the calling process as a result of unsuccessfully 
loading the DLL, termination of the process, or a call to FreeLibrary. 
The DLL can use this opportunity to call the TlsFree function to free any 
TLS indices allocated by using TlsAlloc and to free any thread local 
data. 
Note that the thread that receives the DLL_PROCESS_DETACH 
notification is not necessarily the same thread that received the 
DLL_PROCESS_ATTACH notification.

lpvReserved 
[in] If fdwReason is DLL_PROCESS_ATTACH, lpvReserved is NULL 
for dynamic loads and non-NULL for static loads. 
If fdwReason is DLL_PROCESS_DETACH, lpvReserved is NULL if 
DllMain has been called by using FreeLibrary and non-NULL if DllMain 
has been called during process termination.


Regards,
Gary


In response to

pgsql-hackers by date

Next:From: Ramanujam H S IyengarDate: 2004-06-14 19:34:49
Subject: Re: Coding question
Previous:From: M.Z.Date: 2004-06-14 17:40:57
Subject: ERROR: cannot find attribute 1 of relation resoconti_iq_key ... How can I solve?

pgsql-patches by date

Next:From: Magnus HaganderDate: 2004-06-14 20:49:23
Subject: stderr & win32 admin check
Previous:From: Manfred SpraulDate: 2004-06-14 05:32:37
Subject: Re: [PATCHES] Compiling libpq with VisualC

pgsql-hackers-win32 by date

Next:From: Thomas KellererDate: 2004-06-14 20:50:39
Subject: Re: pg_ctl vs. Windows locking
Previous:From: Tom LaneDate: 2004-06-14 16:39:08
Subject: Re: pg_ctl vs. Windows locking

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group