Re-enable Mach.Port #129
Re-enable Mach.Port #129
Conversation
|
Once apple/swift#66505 is in the nightly compiler, we should be able to merge this. |
glessard
force-pushed
the
reenable-mach-port
branch
from
21145ba
to
c07c20f
Compare
|
@swift-ci please test macOS platform |
glessard
force-pushed
the
reenable-mach-port
branch
from
9899db0
to
c07c20f
Compare
glessard
force-pushed
the
reenable-mach-port
branch
from
5e56655
to
bab1bc5
Compare
This should never have been -1, as there is no send right for it to balance when `RightType.self == ReceiveRight.self`.
glessard
force-pushed
the
reenable-mach-port
branch
from
bab1bc5
to
e67f870
Compare
|
@swift-ci please test |
- this is the situation where it is appropriate
glessard
force-pushed
the
reenable-mach-port
branch
from
b62d6aa
to
e4d06ae
Compare
|
@swift-ci please test |
glessard
force-pushed
the
reenable-mach-port
branch
from
3a919bb
to
8730f2c
Compare
|
@swift-ci please test |
| RightType.self == SendRight.self || | ||
| RightType.self == SendOnceRight.self | ||
| ) | ||
| _machPrecondition(mach_port_deallocate(mach_task_self_, _name)) |
There was a problem hiding this comment.
While this does simplify the logic, it also means the kernel will no longer validate the right type on deinit. e.g. If you have a Mach.Port<Mach.RecieveRight> incorrectly wrapping a send right, the old code would fail this precondition (the mach call would return KERN_INVALID_RIGHT, whereas this new code would (silently, but not incorrectly) decrement the reference count of the send right.
There was a problem hiding this comment.
This is a good point. I went this way because it had ballooned to 6 branches; there is probably a reasonable alternative somewhere in the middle.
There was a problem hiding this comment.
A note from an out-of-band conversation: the previously-used mach_port_mod_refs() calls do not succeed when _name has become a dead name, because it is no longer a send right (or a send-once right.) It is unclear whether there's a reasonable and performant way to re-validate the type of _name in the deinit.
There was a problem hiding this comment.
If we find a better solution for the deinit, we'll update it in another PR.
| _ = consume recv | ||
| // `send` and `send1` have become dead names | ||
| _ = consume send | ||
| _ = consume send1 |
There was a problem hiding this comment.
I like this test case, but no assertions?
There was a problem hiding this comment.
I wasn't sure what we should assert here, to be honest (other than "it did not crash"). I'm open to suggestions.
This better communicates the intention. Co-authored-by: loffgren <117697138+loffgren@users.noreply.github.com>
- It can’t return `Mach.Port<SendRight>`, because a noncopyable type cannot currently be a generic type argument.
|
@swift-ci please test |
Re-enabling was blocked on this issue: apple/swift#66299 (rdar://110496872)
Now it is blocked on rdar://110926824.
Mach.Portwas disabled in commit 7bcc01f of #127Once the fix is merged to https://github.com/apple/swift, then this can be merged.