gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problems compiling NSAnimation.m


From: Xavier Glattard
Subject: Re: problems compiling NSAnimation.m
Date: Wed, 9 May 2007 16:53:01 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Riccardo <multix <at> ngi.it> writes:

> Hi,
> 
> trying to compile NSAnimation on older compilers is a nightmare (like 
> gcc 2.95). I fixed some trivial stuff, but then stopped: the main 
> problem is the _NSANIMATION_LOCK macro. Since this macro defines a 
> variable in it,
> 
> #define _NSANIMATION_LOCK           \
>    BOOL __gs_isLocked = NO;          \
>    if (_isThreaded)                  \
>    {                                 \
>      __gs_isLocked = YES;            \
>      NSDebugFLLog( <at> "NSAnimationLock",\
>                    <at> "% <at>  LOCK % <at> ",self,[NSThread 
> currentThread]);\
>      [_isAnimatingLock lock];        \
>    }
> 
> it causes a hidden "c99-ism" everywhere. If the definition of 
> __gs_isLocked inside the macron can be avoided or the macroitself can 
> be avoided, I think the code would be cleaner.
> 
> Ideas? Who maintains this?
> 
> -Riccardo

I wrote this stuff, so i guess i could help ;-)

I dont know if this can be avoided : i remember i thought very hard and i did
not find any other way to make this class thread-safe and reduce overhead. But i
can't remember why i added __gs_isLocked... Maybe in case of isThreaded becomes
false before the unlock. But it cant (AFAIK)

A 'if(_isThreaded)' might be enough, both in _NSANIMATION_LOCK and
_NSANIMATION_UNLOCK.

Regards

Xavier







reply via email to

[Prev in Thread] Current Thread [Next in Thread]