-
Notifications
You must be signed in to change notification settings - Fork 469
deallocation support for DispatchData on Linux #108
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
Conversation
case 0x00: self = QOS_CLASS_UNSPECIFIED | ||
case 0x11: self = .QOS_CLASS_UTILITY | ||
case 0x09: self = .QOS_CLASS_BACKGROUND | ||
case 0x00: self = .QOS_CLASS_UNSPECIFIED |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not related to primary DispatchData changes; fixing compiler warning (will be an error in Swift3).
@mwwa to review |
__wrapped = dispatch_data_create( | ||
buffer.baseAddress!, buffer.count, nil, _dispatch_data_destructor_default()) | ||
let d = dispatch_data_create(buffer.baseAddress!, buffer.count, nil, _dispatch_data_destructor_default()) | ||
self.init(data: d) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the compiler not force you to make this convenience
because of the self.init?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Not that it's a problem, I just figured it would complain)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Compiler doesn't complain. I think it is allowed because this init is public and the init being calling with self.init is internal. (or there's a compiler bug...)
Deallocation / reference counting support for DispatchData in the wrapping overlay consisting of two main pieces. First, since DispatchData is a struct and dispatch_data_t is a COpaquePointer, we need an intermediate class __DispatchData on which to perform the reference counting operations to enable the backing _dispatch_data_t to be deallocated when they are no longer reachable. I overlooked the mapping of _dispatch_data_t to OS_dispatch_data in Dispatch.apinotes in my initial pull request for the wrapping overlay and as a result all the dispatch_data_t instances were not being reference counted. Second, enable the DispatchData.Deallocator portion of the API. After some experimentation, found a way to have the desired API without getting a reference to _TMBO in the generated code. Left a FIXME because the current approach is sub-optimal in where it converts from Swift blocks to @convention(block) blocks.
4ac4f46
to
d334990
Compare
I updated to resolve the merge conflict with #111. Do we want to merge this? Or are we waiting for the branch with the API changes to get dealt with first? |
I think we can merge this. |
deallocation support for DispatchData on Linux Signed-off-by: Daniel A. Steffen <dsteffen@apple.com>
Deallocation / reference counting support for DispatchData
in the wrapping overlay consisting of two main pieces.
First, since DispatchData is a struct and dispatch_data_t is
a COpaquePointer, we need an intermediate class __DispatchData
on which to perform the reference counting operations to enable
the backing _dispatch_data_t to be deallocated when they are no
longer reachable. I overlooked the mapping of _dispatch_data_t
to OS_dispatch_data in Dispatch.apinotes in my initial pull request
for the wrapping overlay and as a result all the dispatch_data_t
instances were not being reference counted.
Second, enable the DispatchData.Deallocator portion of the API.
After some experimentation, found a way to have the desired API
without getting a reference to _TMBO in the generated code.
Left a FIXME because the current approach is sub-optimal in where
it converts from Swift blocks to @convention(block) blocks.