Initial port of WinObjC's KVO implementation to GNUstep #420
Conversation
|
These changes are based on the patch we’ve been using in our app (see #324) and also contain additional fixes on top of the WinObjC implementation. |
There was a problem hiding this comment.
I would really have liked to upgrade the existing implementation with the few missing features rather than depending on objc2, but having looked at the code the dependency on the runtime library and the degree of optimisation (particularly the fine control of ARC) I can see why that would be difficult.
I'm not sure that the reworking of GSAtomic.h is necessary, but renaming functions with a gs_ prefix seems like a good thing even if it's not needed.
I think the C++ change in GSPThread.h should be removed though, since we aren't using C++ internally.
The rest looks reasonable, once we accept that we are tolerating the internal use of objc2 features (and minor coding style issues), though I can't say I'm familiar with the runtime library internals that the class swizzling depends upon.
|
I think adding the prefix for our atomic macros had been necessary to avoid name clashes with the stdatomic.h header. All the Maybe it would be a good idea to start a list with features that require libobjc2 e.g. in the readme (I think NSURLSession and this so far)? |
Source/NSKVOSupport.m
Outdated
| NSObject (NSKeyValueObserving) | ||
| /** | ||
| @Status Interoperable | ||
| */ |
There was a problem hiding this comment.
We can probably remove all these @Status Interoperable comments from WinObjC.
|
On 12 Jun 2024, at 13:14, Frederik Seiffert ***@***.***> wrote:
I think adding the prefix for our atomic macros had been necessary to avoid name clashes with the stdatomic.h header.
All the extern "C" code should indeed be removed since none of the code is C++ (any more).
Maybe it would be a good idea to start a list with features that require libobjc2 e.g. in the readme (I think NSURLSession and this so far)?
We really aren't supposed to have features that don't work with one compiler/runtime as logn as we are supporting both.
It's inevitable that there are some differences between gnustep built on/for different systems, but portability is a key feature and we don't want major differences.
While NSURLSession currently requires blocks, we are supposed to be getting rid of that dependency (using the pseudo-blocks we use elsewhere), and it shouldn't depend on any other objc2 features (or any libobjc2 stuff) AFAIK.
For KVO, I understood the idea was to have two implementations so while one might perform better than the other, the feature-set is pretty similar either way.
|
If one toolchain does not offer or restricts the capabilities needed, it should not slow down overall progress. Associated Objects (which are used in this KVO implementation) are an example for this. |
|
On 12 Jun 2024, at 15:01, Hugo Melder ***@***.***> wrote:
We really aren't supposed to have features that don't work with one compiler/runtime as logn as we are supporting both.
If one toolchain does not offer or restricts the capabilities needed, it should not slow down overall progress. Associated Objects (which are used in this KVO implementation) are an example for this.
Well yes, a project with portability as a key feature does suffer from some slowdown.
If something that's not generally available (like associated objects) is convenient for a task, you either spend a little time implementing a compatibility layer (there are already various compatibility features between the gnu and gnustep runtimes in gnustep-base), or do things a slightly different way in order to have portable code. That often takes a little longer but it means the project is usable by far more people.
Ganerally I'd advocate adding general purpose compatibility features where sutiable features are available, rather than designing new ones. So probably implementing objc_setAssociatedObject() and objc_getAssociatedObject() for the gnu runtime would be better than implementing a private equivalent for KVO.
|
|
Or of course, as in this case, we can have two KVO implementations ... OK, but not as good from a maintainability point of view as a single implementation. |
I understand your point, but even for NSURLSession, this would mean using the libdispatch APIs with C functions, adding autorelease pools to each C function, and using methods instead of blocks for delegate dispatching. Quite a pain and increase in complexity... |
|
I need to test the changes made to the legacy KVO implementation. |
|
The Signature Cache in NSMethodSignature results in up to 36% speed-up of KVO willChange/didChange dispatching. @rfm can you review the changes to NSMethodSignature, NSKeyValueObserving, and other existing classes? 
|
|
We can shave of another 100-150ms if we reuse change dictionaries. KVO on NSSet's is also really inefficient atm because of a copy operation inside willChange[...] and computation of the changes. |
|
I actually looked at the signature cache code yesterday, and was thinking I should suggest that you commit that separately since it's not actually linked to the KVO code in any way, and it seemed a very clearly good idea! |
|
|
Yes good point @rfm, plus we need to ensure multi-thread support is maintained (see also my comment on the |
It is probably worth then to write a few test cases... |
I cannot see it on GH :( |
triplef
force-pushed
the
kvo_winobjc
branch
3 times, most recently
from
1eebad8
to
dbe8f19
Compare
|
Could we try to get the tests working with the old ObjC runtime as well? Of course we need to flag some tests as hopeful there. But that way we better see the missing functionality. |
Sure! |
triplef
force-pushed
the
kvo_winobjc
branch
2 times, most recently
from
b0743eb
to
64b4f0e
Compare
|
I rebased onto master to fix some merge conflicts. |
|
@rfm what's the status of this PR? Can we merge it, or are there still some tests that need to be refactored for older versions of ObjC? |
|
You were going to address Fred's request for portable testcases. I have done partial fixes recently but afaik there's still quite a bit of broken (ie dependent on Apple/clang specific features) code there. |
…pile-time constant
Fixed in bf40916 |
…d statically construct empty NSSet
Just tested this last patch version, in my main app, where I have the keyPathsForValuesAffectingValueForKey: method already prepared, suddenly started to work with that. Awesome! |
|
We’ve also tested this patch with our apps and found no issues. |
…er domains aswell
|
Seems like the NSURLSession tests fail sometimes because of swiftlang/swift-corelibs-libdispatch#833 This is unrelated. |
Summary:
This pull request introduces an initial port of the Key-Value Observing (KVO) implementation from Microsoft's WinObjC to GNUstep. The existing implementation in GNUstep has various issues (See #324).
Details:
References: