Repository navigation
Conversation
used when deciding whether to release a jobserver tokenProxy weak reference as it seems that it is not dropped at all
387ff40 to
958a88e
Compare
|
@bors try jobs=test-x86_64-gnu-aux |
This comment has been minimized.
This comment has been minimized.
Make `Proxy` weak reference as it seems that it is not dropped at all try-job: test-x86_64-gnu-aux
|
💔 Test for 23ce799 failed: CI. Failed job:
|
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
To sum up the current state:
If I understand correctly (I haven't debugged it yet) the cause of the missing token is not straight in the compiler but because we failed to write it back in |
| helper: OnceLock::new(), | ||
| }); | ||
| let proxy_ = Arc::clone(&proxy); | ||
| let weak_proxy = Arc::downgrade(&proxy); |
There was a problem hiding this comment.
I agree that it's better to drop the Proxy rather than to leak it through an Arc cycle, but I'm still not sure what bad may happen if we don't do it (the only nontrivial piece of logic there is Drop for HelperThread).
There was a problem hiding this comment.
I think the helper thread could still have a token acquired but not yet dropped if a token was requested, but then rustc exits because of an error. By avoiding the arc cycle, the helper thread gets a chance to release the token before the process exits.
| if let Ok(token) = token { | ||
| let mut data = proxy_.data.lock(); | ||
| if let Ok(token) = token | ||
| && let Some(proxy) = weak_proxy.upgrade() |
There was a problem hiding this comment.
| && let Some(proxy) = weak_proxy.upgrade() | |
| && let proxy = weak_proxy.upgrade().unwrap() |
?
If we are here, then the helper thread is still running, and it means the Arc<Proxy> is not yet destroyed.
assert_eq!(read.read(&mut buf).unwrap(), 1);
assert_eq!(write.write(&buf).unwrap(), 1);
|
|
(I think we can merge the |
|
☔ The latest upstream changes (presumably #165563) made this pull request unmergeable. Please resolve the merge conflicts by rebasing. |
Trying to fix tests that fail when we enable two threads in frontend, this is a fix for a test failure when we did not return all tokens for job server. I tested it in top of #162848 with2and222threads and did not reproduce after 200 launches, while it was certainly reproducing after 20-30 launches without this fix.There is a second failure which is an infinite hang that I managed to get one or two times locally (with
222threads). I don't know the reason for it, but maybe this fix will also help as it did not reproduce with it.cc @Kobzol @petrochenkov