Re: [Crystal-cvs] SF.net SVN: crystal:[38283] CS/branches/soc2012/lighter2/apps/tools/ lighter2

Le 07/07/2012 14:13, Steel Style a écrit :
> Le 07/07/2012 05:21, res a écrit :
>> On 07.07.2012 05:20, res wrote:
>>> On 06.07.2012 18:25, [email protected] wrote:
>>>> -    RadMaterial() {refractiveIndex = 1; isTexImageValid=false; 
>>>> produceCaustic= false;}
>>>> +    RadMaterial() {
>>>> +      refractiveIndex = 1; isTexImageValid=false; produceCaustic= 
>>>> false;
>>>> +      lockMutex = new CS::Threading::Mutex();
>>>> +    }
>>> 1. lockMutex leaks.
>>> 2. Why allocate it on the heap anyway? “mutable CS::Threading::Mutex
>>> lockMutex;” (no pointer) should work fine.
>
> Actually it's a dirty fix but I'm looking at how can I put a Mutex 
> without pointer (for the moment I have
> compilation error when I do because Mutex is not copyable). I planned 
> to use RadMateral with a csRefCount
> to prevent member copy.
>
>>> Actually... why lock the material (data) at all?
>>> In theory, since you only access the image data for reading, 
>>> concurrency
>>> shouldn't be an issue...
>>>
>>> -f.r.
>>>
> Yeah it's true in theory, but in pratice the 
> RadMaterial::GetTextureValue which should be read-only
> change our textureImg member by making a copy of the read data to 
> textureImg->rawData member.
> And this is the pointer returned by the 
> ((*textureImg->GetImageData()). So as we will work on this
> pointer we should lock it or the data will be inconsistent.
>
> Steel.
>



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/