-
Notifications
You must be signed in to change notification settings - Fork 25.6k
[jit] Implement torch::jit::deregisterOperator
#35107
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
[jit] Implement torch::jit::deregisterOperator
#35107
Conversation
💊 CircleCI build failures summary and remediationsAs of commit 09d452a (more details on the Dr. CI page):
🕵️ 1 new failure recognized by patternsThe following build failures do not appear to be due to upstream breakages (reran 1 job to discount flakiness):
|
9187879
to
3ef65d2
Compare
Modified diff to workaround global destructor order ambiguity issue. |
This looks reasonable but you should get a review from someone who has actually touched this code before. |
cc @smessmer, how would this interact with c10/jit registry syncing via listener etc.? |
3ef65d2
to
821f3fd
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.
Thank you very much for implementing this, this has been long overdue.
cc @smessmer, how would this interact with c10/jit registry syncing via listener etc.?
That's the line I commented on. This should finally make c10 deregistrations work in a sound way (i.e. call through to also deregister the wrapper from JIT).
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.
@malfet is landing this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
Yeah that's very cool :) also wanted to double check that c10 isn't depending on a critical way on the invariant that ops registered to the jit via listener are definitely present, given that this can be called unilaterally, but it sounds like we're not :) |
821f3fd
to
4b5fce4
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.
@malfet has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
Test Plan: CI + `bin/test_jit --gtest_filter=JitTest.CustomOperators --gtest_repeat=2`
4b5fce4
to
09d452a
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.
@malfet is landing this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
auto raw_ptr = listener.get(); | ||
listeners_.push_back(std::move(listener)); | ||
return RegistrationHandleRAII([this, raw_ptr] { | ||
const auto& found_it = std::find_if(listeners_.begin(), listeners_.end(), [raw_ptr](auto& it) { |
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.
Instead of calling find() here, which could be slow, you could make listeners_
a std::list
and just remember the iterator in the closure. std::list
keeps iterators valid, so that's not an issue.
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.
Will do in follow up PR
Test Plan: CI +
bin/test_jit --gtest_filter=JitTest.CustomOperators --gtest_repeat=2