Re: Please test new NSLock implementation!

[Fred Kiefer]

Interesting, sure this is a valid case of subclassing NSLock.
Great that the different size of the class doesn't matter to you,
otherwise we would have to rethink the current implementation.

Fred

SPUeNTRUP - Kai Henningsen schrieb:
> Hallo Fred,
> 
> Am Fri, 04 Sep 2009 23:37:03 +0200
> schrieb Fred Kiefer <fredkiefer@gmx.de>:
> 
>> But if there isn't any chance that I can convince to to take back the
>> binary incompatible change you made (but who would ever subclass
>> NSLock?), by adding a bit more code to the NSLock.m file, I rather give
>> up here.
> 
> Umm ... I certainly have subclassed NSLock (well, actually
> NSRecursiveLock). The purpose here was adding debug code.
> 
> Just for illustration ...
> 
> extern BOOL fastlocks;
> extern BOOL tracelocks;
> 
> @interface Lock:NSRecursiveLock
> {
>         BOOL    traceme;
>         int     lock_count;
>         NSString        *descr;
>         ThreadVars      *owner;
>         unsigned        last_owner;
>         Lock    *next_held_lock;
>         Lock    *prev_held_lock;
> }
> -(void)desc: (const char *)fi : (int)li : (const char *)fu: (const char *)var;
> -(void)lock: (const char *)fi : (int)li : (const char *)fu;
> -(void)unlock: (const char *)fi : (int)li : (const char *)fu;
> -(void)trace;
> -(ThreadVars*)owner;
> @end
> 
> #define NEWLOCK(lk) do { ASSIGN(lk, AUTONEW(Lock)); [lk desc: __FILE__ : 
> __LINE__ : __PRETTY_FUNCTION__: #lk]; } while (0)
> #define LOCK(lk) [lk lock: __FILE__ : __LINE__ : __PRETTY_FUNCTION__]
> #define UNLOCK(lk) [lk unlock: __FILE__ : __LINE__ : __PRETTY_FUNCTION__]
> 
> Not that it matters in this context - we have no expectation of running
> the executable with any version of the library other that the one it
> was compiled against.
> 
> Mit freundlichen Grüßen aus Münster /
> with kind regards - Kai Henningsen
>