[Top][All Lists]

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

Re: Please test new NSLock implementation!

From: SPUeNTRUP - Kai Henningsen
Subject: Re: Please test new NSLock implementation!
Date: Thu, 17 Sep 2009 11:57:27 +0200

Hallo Fred,

Am Fri, 04 Sep 2009 23:37:03 +0200
schrieb Fred Kiefer <address@hidden>:

> 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;

#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

SPUeNTRUP Software
An der Kleimannbrücke 52
D-48157 Münster, Germany

Reg:    Münster Nr.29047

Fon:    +49 700 CALL CATS (=22552287)
Fon:    +49 251 322 311 0
Fax:    +49 251 322 311 99

Web:    http://www.cats.ms
Mail:   address@hidden

reply via email to

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