Changed files to use interlocked functions

[Paul Vriens]

Hi,

the Janitorial page shows that the "Use Interlocked functions in AddRef
and Release methods" project is finished.

There are however several files (at least 135) that still use the
non-interlocked method. Especially ddraw, d3*, dm*, avifil32 and some
ole/oleaut32.

Do they still need to be changed ?

Cheers,

Paul.

[Mike McCormack]

Paul Vriens wrote:
> the Janitorial page shows that the "Use Interlocked functions in AddRef
> and Release methods" project is finished.
>
> There are however several files (at least 135) that still use the
> non-interlocked method. Especially ddraw, d3*, dm*, avifil32 and some
> ole/oleaut32.
>
> Do they still need to be changed ?

Sure.  I probably didn't catch all occurences of AddRef and Release that 
needed modification.  You can update the Janitorial page yourself by 
submitting a patch against the LostWages CVS which holds the WineHQ website.

Mike

[Paul Vriens]

Hi Mike,
> Paul Vriens wrote:
> > the Janitorial page shows that the "Use Interlocked functions in AddRef
> > and Release methods" project is finished.
> >
> > There are however several files (at least 135) that still use the
> > non-interlocked method. Especially ddraw, d3*, dm*, avifil32 and some
> > ole/oleaut32.
> >
> > Do they still need to be changed ?
>
> Sure.  I probably didn't catch all occurences of AddRef and Release that
> needed modification.  You can update the Janitorial page yourself by
> submitting a patch against the LostWages CVS which holds the WineHQ
> website.
>
> Mike

Are there AddRef's or Releases that don't need the modification? Or is it
OK to modify all of them?

What's the best way to generate mail/patches for this bulk. One email for
each file/dll? Inline or attached?

Cheers,

Paul.

[Mike McCormack]

Paul Vriens wrote:
> Are there AddRef's or Releases that don't need the modification? Or is it
> OK to modify all of them?

I think it should be safe to do all of them.  InterlockedIncrement is 
inline, so it shouldn't have any performance penalty.

It may not strictly be necessary for objects in single threaded 
apartments, but at least nobody will copy thread unsafe code into an 
object that lives in a multi threaded apartment.
> What's the best way to generate mail/patches for this bulk. One email for
> each file/dll? Inline or attached?

I'd do one per dll.

Mike

[Rob Shearman]

Paul Vriens wrote:
> Hi Mike,
>
> Are there AddRef's or Releases that don't need the modification? Or is it
> OK to modify all of them?

Theoretically, COM classes that are registered with 
"ThreadingModel"="Apartment" do not need to use the atomic 
increment/decrement functions as they shouldn't be accessed by more than 
one thread at a time, but it shouldn't hurt to change them anyway.
> What's the best way to generate mail/patches for this bulk. One email for
> each file/dll?

One patch for each DLL should be a good balance of reviewability and 
amount of work for Alexandre.
> Inline or attached?

Whatever is easiest for you.

Rob

[Dimitrie O. Paun]

On Tue, Jan 04, 2005 at 02:59:45PM +0100, Paul Vriens wrote:
> Are there AddRef's or Releases that don't need the modification? Or is it
> OK to modify all of them?

I think it's OK to modify them all.
> What's the best way to generate mail/patches for this bulk. One email for
> each file/dll? Inline or attached?

One email per patch, one patch per dll, inlined.

-- 
Dimi.