Biot Olivier said:
> I would however not yet try to build libethereal.dll as such for
> official releases, as it is definitely not multithread-safe and MS
> explicitly demands shared libraries to be MT-safe (I think it has to do
> with the data portion controlled by the DLL in case multiple
> applications use the DLL at the same time -- pls correct me if I am
> wrong).
While DLLs can *have* a region of data shared by all processes using the
DLL, by default data is per-process:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_how_do_i_share_data_in_my_dll_with_an_application_or_with_other_dlls.3f.asp
"Win32 DLLs are mapped into the address space of the calling process. By
default, each process using a DLL has its own instance of all the DLLs
global and static variables. If your DLL needs to share data with other
instances of it loaded by other applications, you can use either of the
following approaches:
o Create named data sections using the data_seg pragma.
o Use memory mapped files. See the Win32 documentation on memory
mapped files."
(UN*X dynamically linked shared libraries are similar, except that there's
no equivalent to "create named data sections using the data_seg pragma" in
most if not all UN*X DLL mechanisms, and you can, on many UN*Xes, use
System V shared memory as well as memory-mapped files.)
So Lars is, as far as I know, right - a DLL is, by default, safe for
multiple processes. (WinPcap has the usual libpcap global variables in
the filter expression compiler, but does work as a DLL; it's not safe to
run "pcap_compile()" in two threads at the same time, on Windows *OR*
UN*X, but it's safe to run it in multiple processes at the same time on
all platforms.)
