[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Please test new NSLock implementation!
From: |
Fred Kiefer |
Subject: |
Re: Please test new NSLock implementation! |
Date: |
Fri, 04 Sep 2009 23:37:03 +0200 |
User-agent: |
Thunderbird 2.0.0.22 (X11/20090605) |
David Chisnall schrieb:
> On 4 Sep 2009, at 23:04, Fred Kiefer wrote:
>
>> The problem there is that the ObjC runtime doesn't include a recursive
>> lock mechanism. This is one of the strong points in David's code, he
>> uses the native pthread support for recursive locks, which makes
>> implementing NSRecursiceLock so much easier.
>
> Actually, this is incorrect. The ObjC runtime ONLY includes recursive
> locks. If the existing code was written on the assumption that this is
> not the case, then it was wrong. Windows, similarly, only provides
> recursive locks, but the abstraction layer implements the recursive
> behaviour in the portable code, so these are still used as if they were
> non-recursive mutexes, which is painfully inefficient and error-prone.
I really don't know, I was assuming the underlying mutex in objc was
only guaranteed to be a non-recursive one, as we implemented recursive
locks on top of normal ones. I also couldn't find a reference for this
and wont be looking through all the different implementations the
runtime offers here to decide which is true, so I just take your word here.
>> Using pthread directly in
>> base is OK, but we should hide it from users of base and not spill it on
>> to user application code.
>
> I agree in principle, but so far all of the proposed solutions have been
> worse than the perceived problem. At worst, we are leaking some symbols
> into the user's code symbol table, but given that these are symbols are
> already going to be provided to the linker, this seems like a minor
> matter - the worst it does is provide a little error checking and throws
> errors early if they declare functions that match the pthread functions
> (which, given that all of the pthread functions and types are prefixed
> with pthread_ seems unlikely).
>
> Note that we already do this with several of the libobjc headers; GNU
> runtime functions are exposed in all code that imports Foundation.h on
> GNUstep, while OS X requires the runtime headers to be explicitly
> included for the equivalent functionality to be accessed. No one, to my
> knowledge, has objected to this.
This is different, although I also would prefer to avoid this.
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.
You did understand that for FreeBSD and other systems where
pthread_mutex_t fits into a pointer this wouldn't even be a runtime
overhead, as no extra indirection is needed, didn't you?
Fred
- Re: Please test new NSLock implementation!, (continued)
- Re: Please test new NSLock implementation!, Richard Frith-Macdonald, 2009/09/02
- Re: Please test new NSLock implementation!, Fred Kiefer, 2009/09/02
- Message not available
- Re: Please test new NSLock implementation!, Fred Kiefer, 2009/09/03
- Re: Please test new NSLock implementation!, Wolfgang Lux, 2009/09/04
- Re: Please test new NSLock implementation!, Scott Christley, 2009/09/04
- Re: Please test new NSLock implementation!, David Chisnall, 2009/09/04
- Re: Please test new NSLock implementation!, Fred Kiefer, 2009/09/04
- Re: Please test new NSLock implementation!, David Chisnall, 2009/09/04
- Re: Please test new NSLock implementation!,
Fred Kiefer <=
- Re: Please test new NSLock implementation!, SPUeNTRUP - Kai Henningsen, 2009/09/17
- Re: Please test new NSLock implementation!, Fred Kiefer, 2009/09/18
- Re: Please test new NSLock implementation!, Richard Frith-Macdonald, 2009/09/06
- Re: Please test new NSLock implementation!, Fred Kiefer, 2009/09/06