Asynchronous Operations


(Ian Partridge) #1

On Darwin, asynchronous usage of Operation is supported via KVO
notifications.

Because KVO is only available on Darwin platforms,
swift-corelibs-foundation currently does not support asychronous
Operations, and there is a comment to that effect:

https://github.com/apple/swift-corelibs-foundation/blob/6c2afef20330681ec1f8e4e4e3e2664bfd758888/Foundation/NSOperation.swift#L50

My understanding is that it's unlikely KVO will arrive on Linux any time
soon, so this leaves us with a problem in Operation. Asynchronous usage of
Operation is an important feature.

Is there any way that we could support asynchronous operations in
swift-corelibs-foundation, in the absence of KVO?

Might it be acceptable to add extra temporary public API to enable this?

Many thanks,

···

--
Ian Partridge


(Philippe Hausler) #2

On Darwin, asynchronous usage of Operation is supported via KVO notifications.

Because KVO is only available on Darwin platforms, swift-corelibs-foundation currently does not support asychronous Operations, and there is a comment to that effect:

https://github.com/apple/swift-corelibs-foundation/blob/6c2afef20330681ec1f8e4e4e3e2664bfd758888/Foundation/NSOperation.swift#L50

My understanding is that it's unlikely KVO will arrive on Linux any time soon, so this leaves us with a problem in Operation. Asynchronous usage of Operation is an important feature.

Is there any way that we could support asynchronous operations in swift-corelibs-foundation, in the absence of KVO?

So perhaps you misunderstood my comment? What are you meaning by asynchronous operation? Technically all operations running in a queue are “asynchronous” on Darwin or on Linux.

My commentary was about the cases where main finishes execution and the operation is not finished.

The subclassers of Operation would need to somehow notify the super-class that the operation is finished. And we would need to have a mechanism to understand if the subclasser is overriding main or start (or both?!)

Might it be acceptable to add extra temporary public API to enable this?

There is never a thing as temporary API - it haunts us for ever :wink:

I think it would be better to advocate a sound design pattern that would facilitate proper implementations on all platforms instead… Perhaps like; how does one properly use run loops in the context of Operation or dispatch. Often that is a suitable way to make things that act asynchronously without consuming another thread/queue.

···

On Jan 20, 2017, at 7:55 AM, Ian Partridge via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

Many thanks,

--
Ian Partridge

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Matthew Johnson) #3

On Darwin, asynchronous usage of Operation is supported via KVO notifications.

Because KVO is only available on Darwin platforms, swift-corelibs-foundation currently does not support asychronous Operations, and there is a comment to that effect:

https://github.com/apple/swift-corelibs-foundation/blob/6c2afef20330681ec1f8e4e4e3e2664bfd758888/Foundation/NSOperation.swift#L50

My understanding is that it's unlikely KVO will arrive on Linux any time soon, so this leaves us with a problem in Operation. Asynchronous usage of Operation is an important feature.

Is there any way that we could support asynchronous operations in swift-corelibs-foundation, in the absence of KVO?

Might it be acceptable to add extra temporary public API to enable this?

+ 1. IMO eliminating the dependence of an API like this on KVO would be a good thing regardless of whether KVO is present or not.

···

On Jan 20, 2017, at 9:55 AM, Ian Partridge via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

Many thanks,

--
Ian Partridge

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Brent Royal-Gordon) #4

Could we add `willChangeValue(forKey:)` and `didChangeValue(forKey:)` methods just to `Operation` which only handle an `isFinished` key? Presumably they'd just look like:

  public func willChangeValue(forKey key: String) {
    // do nothing
  }
  public func didChangeValue(forKey key: String) {
    if key == "isFinished" && isFinished {
      finish()
    }
  }

I believe that would make existing code just work without needing to do anything special.

···

On Jan 20, 2017, at 7:55 AM, Ian Partridge via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

Is there any way that we could support asynchronous operations in swift-corelibs-foundation, in the absence of KVO?

--
Brent Royal-Gordon
Architechies


(Tony Parker) #5

Hm, that’s probably the least bad option we have at the moment.

I don’t want to introduce “new” API, as it is unlikely we will be able to remove it when whatever permanent solution comes up.

- Tony

···

On Jan 21, 2017, at 6:09 AM, Brent Royal-Gordon via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

On Jan 20, 2017, at 7:55 AM, Ian Partridge via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

Is there any way that we could support asynchronous operations in swift-corelibs-foundation, in the absence of KVO?

Could we add `willChangeValue(forKey:)` and `didChangeValue(forKey:)` methods just to `Operation` which only handle an `isFinished` key? Presumably they'd just look like:

  public func willChangeValue(forKey key: String) {
    // do nothing
  }
  public func didChangeValue(forKey key: String) {
    if key == "isFinished" && isFinished {
      finish()
    }
  }

I believe that would make existing code just work without needing to do anything special.

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Ian Partridge) #6

Thank you everyone for your comments.

Adding willChangeValue(forKey:) and didChangeValue(forKey:) to
Operation does solve the problem for me. The Swift 3 code I'm porting
from macOS to Linux works correctly when I patch Foundation as Brent
suggests.

I've opened a PR against swift-corelibs-foundation and would welcome
feedback on this. Thank you.

https://github.com/apple/swift-corelibs-foundation/pull/836

P.S. The code I'm porting is roughly analogous to
https://gist.github.com/ianpartridge/e3b8496cb114005a93f5c86ff76af630
although it uses URLSession instead of an async dispatch queue.

···

On 23 January 2017 at 17:32, Tony Parker <anthony.parker@apple.com> wrote:

Hm, that’s probably the least bad option we have at the moment.

I don’t want to introduce “new” API, as it is unlikely we will be able to remove it when whatever permanent solution comes up.

- Tony

On Jan 21, 2017, at 6:09 AM, Brent Royal-Gordon via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

On Jan 20, 2017, at 7:55 AM, Ian Partridge via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

Is there any way that we could support asynchronous operations in swift-corelibs-foundation, in the absence of KVO?

Could we add `willChangeValue(forKey:)` and `didChangeValue(forKey:)` methods just to `Operation` which only handle an `isFinished` key? Presumably they'd just look like:

      public func willChangeValue(forKey key: String) {
              // do nothing
      }
      public func didChangeValue(forKey key: String) {
              if key == "isFinished" && isFinished {
                      finish()
              }
      }

I believe that would make existing code just work without needing to do anything special.

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

--
Ian Partridge