Mike Hearn wrote:
On Mon, 10 Jan 2005 18:03:30 +0100, Joris Huizer wrote:
Paul Vriens was posting patches in which references to This->ref in
TRACE calls were replaced by a variable containing the value of
This->ref - I can't remember why this was necessary, but I don't think
he's doing it just
Mike McCormack wrote:
The most important reason in my mind to do this is so that people
implementing objects in the future copy code that uses the
Interlocked* functions. There's no overhead to using those
functions... no penalty if we use them in code that doesn't need to be
thread safe, so w
On Mon, 10 Jan 2005 18:03:30 +0100, Joris Huizer wrote:
> Paul Vriens was posting patches in which references to This->ref in
> TRACE calls were replaced by a variable containing the value of
> This->ref - I can't remember why this was necessary, but I don't think
> he's doing it just for the fu
On Mon, 10 Jan 2005 22:42:22 +, Mike McCormack wrote:
> Well, it's true that some objects don't need to be thread safe, however
> it's not recorded anywhere in the Wine source which object need to be
> thread safe and which don't.
That info is usually available in MSDN or the registry. But I
Mike Hearn wrote:
On Mon, 10 Jan 2005 11:38:20 +0100, Joris Huizer wrote:
To see how far we are, I tried grepping to get This->refs stuff
grep -r -n -e 'TRACE(.*This->ref)' *
grep -r -n "++(This->ref)" *
grep -r -n -- "--(This->ref)" *
I hope there are a lot of false positives there :-/
You re
Mike Hearn wrote:
To be quite honest I'm not convinced this janitorial task is a good idea.
It makes the code look at first glance like it's thread safe when it
actually isn't. A better janitorial task would simply be "Make
free-threaded COM objects thread safe" except that making code thread safe
On Mon, 10 Jan 2005 11:38:20 +0100, Joris Huizer wrote:
> To see how far we are, I tried grepping to get This->refs stuff
> grep -r -n -e 'TRACE(.*This->ref)' *
> grep -r -n "++(This->ref)" *
> grep -r -n -- "--(This->ref)" *
>
> I hope there are a lot of false positives there :-/
You real
To see how far we are, I tried grepping to get This->refs stuff
grep -r -n -e 'TRACE(.*This->ref)' *
grep -r -n "++(This->ref)" *
grep -r -n -- "--(This->ref)" *
I hope there are a lot of false positives there :-/
regards,
Joris
On Tue, 2005-01-04 at 21:48, Alexandre Julliard wrote:
> Paul Vriens <[EMAIL PROTECTED]> writes:
>
> > TRACE("(%p)->()\n", iface);
> > -if (!--This->refCount)
> > +if (!InterlockedDecrement(&This->refCount))
> > {
> > CoTaskMemFree(This->ppFilters);
> > CoTaskMe
Paul Vriens <[EMAIL PROTECTED]> writes:
> TRACE("(%p)->()\n", iface);
> -if (!--This->refCount)
> +if (!InterlockedDecrement(&This->refCount))
> {
> CoTaskMemFree(This->ppFilters);
> CoTaskMemFree(This);
You also need to store the result of the decrement and ha
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? Inl
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 a
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
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-interloc
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
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
16 matches
Mail list logo
