Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Streamlined the mechanics behind composed properties. #340

Merged
merged 4 commits into from
May 15, 2017

Conversation

andersio
Copy link
Member

@andersio andersio commented Apr 21, 2017

  1. Replaced replayLazily(upTo:) with a custom implementation.

    Composed properties now cache only one copy of the latest value, down from 1-2 copies currently. Moreover, it now stops caching after both the Property and all the producer instances has deinitialised.

init(_ value: Value) {
self.value = value
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to see this use the same approach as Atomic to prevent unsafe accesses—hiding value and lock behind locking APIs.

}

extension NSRecursiveLock {
fileprivate func sync<Result>(_ action: () throws -> Result) rethrows -> Result {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this can go away of appropriate methods are added to PropertyBox.

@andersio andersio requested a review from mdiep May 11, 2017 09:44
fileprivate func sync<Result>(_ action: () throws -> Result) rethrows -> Result {
lock(); defer { unlock() }
return try action()
func modifyDidSet<Result>(_ action: (inout Value) throws -> Result, didSet: (() -> Void)?) rethrows -> Result {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just make this:

func modify<Result>(
    _ action: (inout Value) throws -> Result,
    didSet (() -> Void)? = nil
) rethrows -> Result {

?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I thought the trailing closure would be in conflict. But I just realize didSet can be moved as the first. 😛

}
}, didSet: {
observer.action(event)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't observer.action be in the action block? It still happens inside the lock either way.

Copy link
Member Author

@andersio andersio May 11, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would violate access exclusivity because of the "de jure" copy-in, copy-out semantic of inout being in conflict with the guarantee of property observers always seeing the latest value.

Copy link
Member Author

@andersio andersio May 11, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, MutableProperty.modify needs to be changed too.

@andersio andersio requested a review from mdiep May 11, 2017 12:33
@andersio andersio force-pushed the property-refactor branch 7 times, most recently from b395238 to af6a7f6 Compare May 13, 2017 09:35
// default. Since fairness is not a concern of our reactive primitives
// anyway, it can be disabled.
pthread_mutexattr_setpolicy_np(attr, _PTHREAD_MUTEX_POLICY_FIRSTFIT)
#endif
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't love setting an untested (in the real world) policy for only older Apple OSes.

Because this would affect a small portion of devices, it's hard to have confidence that it works well. I'd rather see us take a performance hit on older OS versions and not have a separate code path that's hard to test.

@mdiep mdiep merged commit e46fb3e into master May 15, 2017
@mdiep mdiep deleted the property-refactor branch May 15, 2017 20:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants