Add data(from:delegate:) method.
#4705
Conversation
|
@parkera |
|
@jrflat |
|
@swift-ci test |
| @@ -28,7 +28,7 @@ private class Bag<Element> { | |||
|
|
|||
| /// A cancelable object that refers to the lifetime | |||
| /// of processing a given request. | |||
| open class URLSessionTask : NSObject, NSCopying { | |||
| open class URLSessionTask : NSObject, NSCopying, @unchecked Sendable { | |||
There was a problem hiding this comment.
Has this class been audited for thread-safety to get this Sendable annotation?
There was a problem hiding this comment.
In Foundation on Apple platforms, URLSessionTask has already conformed to Sendable. So, I naturally assume that the URLSessionTask in Core Foundation could also conform to Sendable. Do you think any detailed audits are necessary?
If we need additional audits, I'd like to contribute to it. However, I'm not sure how to audit for thread-safety of this class. Could you please give me your advice?
There was a problem hiding this comment.
In Foundation on Apple platforms,
URLSessionTaskhas already conformed toSendable. So, I naturally assume that theURLSessionTaskin Core Foundation could also conform toSendable.
URLSessionTask is implemented in Foundation proper, it's not present in CoreFoundation. You can confirm that by searching the CoreFoundation directory.
Do you think any detailed audits are necessary?
Yes, of course. If something is marked as Sendable in Foundation on Darwin platforms, it means that an audit was done and necessary changes that make it thread-safe applied if needed on it. Since these are different codebases, it has to be done separately in this repository too.
If we need additional audits, I'd like to contribute to it. However, I'm not sure how to audit for thread-safety of this class. Could you please give me your advice?
I don't think there's anything specific to this repository when compared to a general thread-safety audit on an arbitrary codebase. As a bare minimum one would have to confirm that mutable state accessible from different threads is either synchronized or made immutable. If there's a class hierarchy involved, this has to be done to mutable state inherited from superclasses too. In Swift I'd probably start with making a type Sendable (not @unchecked Sendable) and then auditing and adding matching sendability annotations to types involved in those warnings.
|
@b1ackturtle Sorry for the slow review here, thanks for your work on this! I built on top of your commit in #4970 to add the remaining async methods and address the Sendability requirement without marking |
|
@jrflat |
|
Should we close this PR now that #4970 has landed? |
Related issue: #3205