Re: [OLE #2] Provide Reference Implementation of DllCanUnloadNow

[Dmitry Timoshkov]

"Robert Shearman"  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.

[OLE #2] Provide Reference Implementation of DllCanUnloadNow

[Robert Shearman]

Dmitry Timoshkov wrote:
> "Robert Shearman"  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

[OLE #2] Provide Reference Implementation of DllCanUnloadNow

[Dmitry Timoshkov]

"Robert Shearman"  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.

[OLE #2] Provide Reference Implementation of DllCanUnloadNow

[Robert Shearman]

Dmitry Timoshkov wrote:
> "Robert Shearman"  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

[OLE #2] Provide Reference Implementation of DllCanUnloadNow

[Mike Hearn]

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

[OLE #2] Provide Reference Implementation of DllCanUnloadNow

[Alexandre Julliard]

Robert Shearman  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?").