Repository navigation
mw_procs: the victim of a kill is killed after it has inserted, not after a fixed time - #3
Merged
Merged
Conversation
…fter a fixed time The test killed a process 400 ms (one process) and 600 ms (all four) after it started it. On a slow runner the process had not inserted anything yet: "one process killed after 0 of 1000000 inserts", "FAIL mw_procs.c:126: killed > 0 && killed < 1000000" (linux-arm64 of main, 15:21 UTC). The data were whole: only the time did not hold. wait_acked() waits until the process has acknowledged n inserts (a byte in its .ack file for each), at most a minute, and the kill follows: 200 inserts for the one of phase 2, 100 for each of the four of phase 3. The size is read from an open handle (lseek): on Windows stat() of a file that another process holds open lags behind. Checked with the children of the test started 700 ms late: the old test fails as in CI (killed after 0 of 1000000 inserts), the new one passes (258 and 201 inserts before the kill). The checks of the end are the same. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Il problema
Su
main(run38150066532, tentativo 2) il joblinux-arm64 build + testè fallito sumw_procs:Il test uccide un processo 400 ms dopo averlo avviato (fase 2) e tutti e quattro dopo 600 ms (fase 3). Su un runner lento il processo non aveva ancora inserito nulla: i dati erano integri, non reggeva solo il tempo.
Correzione
wait_acked(path, id, n, limit_ms)attende che il processo abbia confermato almenoninserimenti (un byte nel suo file.ackper ciascuno; limite 60 s) e solo dopo lo uccide:pause_ms(400)pause_ms(600)La dimensione del file è letta da un handle aperto (
open+lseek), non constat(): su Windows la dimensione di un file che un altro processo tiene aperto risulta in ritardo. I controlli finali sono invariati (nessuna riga confermata persa, al più una in più, database integro).Verifica
killed after 0 of 1000000 inserts,FAIL ... killed > 0) in entrambi i giri; quello nuovo passa (uccide dopo 258 e 201 inserimenti).Da sapere
open/lseek/close, già disponibili nel test per.ackeunlink.mw_syncwindow(fallito nella stessa run al tentativo 1): è un altro test temporizzato (mw_mp=1, ritardi di 15 e 30 ms) e non l'ho riprodotto né prima né dopo, quindi non lo tocco qui.🤖 Generated with Claude Code