On Windows, in certain scenarios of unloading sal3.dll it happens that the
process deadlocks.  The main thread calls sal3.dll's DllMain
(DLL_PROCESS_DETACH), which calls rtl_cache_wsupdate_fini, which blocks in
WaitForSingleObject on the m_update_thread.  The m_update_thread has already
returned from its rtl_cache_wsupdate_all function, but is blocked in some
sysenter instruction.  The MS "Best Practices for Creating DLLs" document
(available from <http://www.microsoft.com/whdc/driver/kernel/DLL_bestprac.mspx>)
states:  "You should never perform the following tasks from within DllMain:
[...] Synchronize with other threads.  This can cause a deadlock."

A simple scenario in which the deadlock can be observed is the attached
deadlock.patch, which in the sal code module creates and runs a small C
application that dynamically loads and frees sal3.dll.  (I stumbled over this
problem in a similar scenario, where the DllPlugInTester_dll.exe that is part of
CppUnit 1.12.1 dynamically loads and frees a test library that links against
sal3.dll.)  The problem seems not to appear with typical OOo executables that
use sal3.dll, maybe because those executables are themselves linked against
sal3.dll.