Re: [OLE #2] Provide Reference Implementation of DllCanUnloadNow
"Robert Shearman" <rob(a)codeweavers.com> wrote:
-DWORD dll_ref = 0; +LONG cLocks; ... +/********************************************************************** + * Dll lifetime tracking declaration + */ +void LockModule() +{ + InterlockedIncrement(&cLocks); +} + +void UnlockModule() +{ + InterlockedDecrement(&cLocks); +}
Perhaps it would be better to prefix both a variable and lock/unlock interfaces with a module name, in this case "DEVENUM_" since they are global and externally visible. -- Dmitry.
Dmitry Timoshkov wrote:
"Robert Shearman" <rob(a)codeweavers.com> wrote:
-DWORD dll_ref = 0; +LONG cLocks;
...
+/********************************************************************** + * Dll lifetime tracking declaration + */ +void LockModule() +{ + InterlockedIncrement(&cLocks); +} + +void UnlockModule() +{ + InterlockedDecrement(&cLocks); +}
Perhaps it would be better to prefix both a variable and lock/unlock interfaces with a module name, in this case "DEVENUM_" since they are global and externally visible.
Do we still need to worry about that crap even though we don't link directly to other DLLs anymore? Rob
"Robert Shearman" <rob(a)codeweavers.com> wrote:
Perhaps it would be better to prefix both a variable and lock/unlock interfaces with a module name, in this case "DEVENUM_" since they are global and externally visible.
Do we still need to worry about that crap even though we don't link directly to other DLLs anymore?
That's not a crap in the ELF world, and I'm not sure whether Wine DLLs aren't affected by it. -- Dmitry.
Dmitry Timoshkov wrote:
"Robert Shearman" <rob(a)codeweavers.com> wrote:
Perhaps it would be better to prefix both a variable and lock/unlock interfaces with a module name, in this case "DEVENUM_" since they are global and externally visible.
Do we still need to worry about that crap even though we don't link directly to other DLLs anymore?
That's not a crap in the ELF world,
It is because it makes loader performance suck and it makes us programmers have to worry about implementation details of other shared objects. Rob
On Wed, 01 Dec 2004 21:41:42 -0600, Robert Shearman wrote:
Do we still need to worry about that crap even though we don't link directly to other DLLs anymore?
I don't think we do, winelib DLLs are linked using -Bsymbolic meaning global symbols internal to the library cannot be overridden by other libraries like you would be able to normally. If we still have problems with symbol interference we should apply a versioning script to suppress ELF exports. So I'd stick with just LockModule(). In fact the DLLNAME_ prefixes are quite ugly, maybe it should be a janitorial task to get rid of them. thanks -mike
Robert Shearman <rob(a)codeweavers.com> writes:
Dmitry Timoshkov wrote:
Perhaps it would be better to prefix both a variable and lock/unlock interfaces with a module name, in this case "DEVENUM_" since they are global and externally visible.
Do we still need to worry about that crap even though we don't link directly to other DLLs anymore?
We don't have to use separate names, but it's a good idea anyway, since it makes life easier with grep, winedbg, etags, etc. In any case, please don't make internal functions look like Windows APIs; if you don't want a DEVENUM_ prefix, then name it lock_module() or something like that. Also please change the "cLocks" name, that's really confusing ("what has a clock got to do with the ref count?"). -- Alexandre Julliard julliard(a)winehq.org
participants (4)
-
Alexandre Julliard -
Dmitry Timoshkov -
Mike Hearn -
Robert Shearman