-
Notifications
You must be signed in to change notification settings - Fork 88
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
Remove Pinned #983
Remove Pinned #983
Conversation
3617a81
to
c11e038
Compare
I think it is possible that I introduced a memory leak. Can we profile the memory consumption of |
We'll sure, you could accumulate the sizes of all allocs minus all deallocs somewhere and compare. |
c11e038
to
6cd602c
Compare
I've tested the branch with |
Thanks for testing! How much memory did the VM get? |
I am not on my computer right now, so I cannot check to be sure but if I recall correctly, ~95 MB during the test and ~80 MB at idle. The VM limit was the xtask default (128 MB (?)). |
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.
Thanks, this looks great! :)
Sorry for taking so long with the review.
Just a few remarks regarding the introduction of additional unsafe
blocks.
8c842a3
to
293703f
Compare
Looking closer at the uses of unsafe, I think they are fundamentally not thread-safe. It is possible to use synchronization to make it safe, but I realized that the only uses of shared Transfers are inside the module itself to check for Transfer status and they can be avoided. The latest commit does that. If it is preferable to keep the possibility to check status through the Transfer for future use, we can also switch to using synchronization. I kept the initial commit (the one with reference counting) to make it more convenient to review the changes to the original PR and to switch back to the Rc approach if necessary. The two commits can be squashed if the approach described above is acceptable. |
293703f
to
276f15b
Compare
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.
Thanks a lot! This looks great.
Just one question about MaybeUninit
inline.
Another question: Is the PR description still up to date?
You mention one-bit refcounts. What do you mean with that? I mean a refcounter that can only count to one is exactly the same as just having a single owner.
The description also talks about replacing Pinned<T>
with Rc<T>
, but to me, the code reads more like replacing it with Box<T>
and T
, which is good, I was just wondering about the description. :)
It seems like Pinned was more of a single bit reference counter than an actual Pin. This commit replaces it with Rc.
Sharing the transfer with the sender is not really necessary, they can be notified through a await queue. Change the relevant methods to let the virtqueue own the Transfers and avoid reference counting complications.
276f15b
to
b3d0c1c
Compare
I've updated the PR description and implemented the change from MaybeUninit to Option. |
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.
Thanks a lot! :)
Pinned was used to keep track of if a raw pointer to the object was handed out via the use of a boolean and free or not free accordingly. The initial commit replaces it with Rc to keep track of the sharing in a standard and safer way. The second commit eliminates the need to keep track of shares completely by removing the sharing of
TransferToken
s and adapting the only instance of the use of the returnedTransferToken
.