On 10 May 2007, at 16:23, Xavier Glattard wrote:
Nicola Pero <nicola.pero <at> meta-innovation.com> writes:
(...)
very confusing, because when the second declaration of c is reached,
you need to be a C standard lawyer to know what happens
Yes, but only a C-riminal would do such a thing ;-)
(...)
What about adding a macro
_NSANIMATION_SETUP
That sounds good and elegant. But IMHO it would be far easier
to DELETE any reference to __gs_isLocked and only test _isThreaded.
Unless someone can explain why i wrote such a piece of code... ;-)
I thought it was to check for unbalanced lock/unclock sequences.
I grabbed GSTest from svn, and after fixing it to install the
animation tests properly, I ran them.
It crashed with my version of the code.
It also crashed with the version from yesterday (before I made any
changes).
So to simplify, I removed all the code to try and optimise for
unthreaded operation, and was able to get the test working.
Maybe it's worth re-introducing the optimisation to avoid locking
when not using threads, but that's tricky to get right (especially if
there is any possibility of the threading mode changing while an
animation is in progress). Is the locking really a major overhead,
or would it be better to keep the code simple?
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
