Resuming read after timeout
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- rust
- Ambito
- cli, operating-systems
Direzione di ricerca
Inizia esaminando rexpect::exp_eof e il percorso reader.try_read utilizzato da drain_read_buffer, concentrandoti su ciò che rimane nel buffer dopo un timeout. Definisci cosa dovrebbe restituire «leggi tutto ciò che è disponibile dopo 100ms» e come le letture successive dovrebbero evitare di restituire nuovamente l'output precedente; valida il comportamento con un processo PTY che produce output in modo incrementale.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
I have a
pub session: Option<Arc<Mutex<PtySession>>>,
I want to get the existing output of a process after 100ms. This seemed to work at first:
let output = {
let session_mutex = self.session.as_mut().ok_or(anyhow!("No session"))?;
let mut session = session_mutex.lock()?;
match session.exp_eof() {
Ok(output) => output,
Err(e) => {
match e {
rexpect::error::Error::Timeout { got, .. } => got
.replace("`\\n`\n", "\n")
.replace("`\\r`", "\r")
.replace("`^`", "\u{1b}"),
_ => return Err(e.into()),
}
}
}
};
but then I realized that session.exp_eof does not drain the buffer if a timeout is reached, meaning that if I try to read the next chunk, the entire output up to this point is going to be returned yet again. This seems to work:
fn drain_read_buffer(&mut self) -> ZammResult<String> {
let mut output = String::new();
if let Some(session) = self.session.as_mut() {
let reader = &mut session.lock()?.reader;
while let Some(chunk) = reader.try_read() {
output.push(chunk);
}
}
Ok(output)
}
...
let mut output = String::new();
loop {
sleep(Duration::from_millis(100));
let new_output = self.drain_read_buffer()?;
if new_output.is_empty() {
break;
}
output.push_str(&new_output);
}
But I'm wondering, is there a better way to implement "read whatever is available after 100ms" than this?
- Lingua principale
- Rust
- Stelle
- 391
- Fork
- 69
- Merge medio
- 1g 34m
- PR unite (30g)
- 2
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di rust-cli/rexpect
-
Strict output expectations Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 38/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 45/100
-
Configurable sleeps Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 48/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 25/100
Tutte le issue di rust-cli/rexpect
Issue simili
-
Browser (wasm) relay client cannot connect to relays whose URL has a trailing-dot FQDN hostname Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
n0-computer/iroh#4550 ·
-
impl detach for native Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
paritytech/zombienet-sdk#591 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
farion1231/cc-switch#7638 · 1 commento ·
-
onnx-ir re-exports ModelProto and GraphProto but not NodeProto, AttributeProto and AttributeType Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100