Looks like we're resuming the target during snapshots again
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Error
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- rust
- Área
- devtools, operating-systems
Línea de trabajo
Comienza rastreando el proceso de snapshot de tareas y el código donde se imprime la hora del sistema capturada y se compara con los temporizadores de las tareas. Reproduce el snapshot incoherente descrito en el issue y, a continuación, verifica que el objetivo permanezca detenido durante toda la captura del snapshot y que los valores de los temporizadores de las tareas y el estado de las tareas ejecutables sean coherentes.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
I was on Mastodon trumpeting the fact that Humility mostly works with my keyboard when I noticed...a party pooper.
It's subtle, but: see how scanner has its timer set for T+10?
scanner always sets its timer for T+1. It sleeps for one millisecond at a time.
So why would Humility show it with a timer set for T+10? Because Humility captures the system time early in the process (see where it's printed up top) and uses that value to compare to task timers. The T+10 means that it's resumed the target for 9 ms during the task snapshot process, generating an inconsistent snapshot.
I can reproduce inconsistent snapshots here pretty reliably -- for instance, getting output where no tasks are running despite being runnable (the idle task, at least, should show as running!).
This suggests to me that the issue where we're not reliably halting during snapshots has regressed. 😢
- Lenguaje dominante
- Rust
- Estrellas
- 587
- Forks
- 64
- Merge medio
- 2 d 1 h
- PR fusionados (30 d)
- 7
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de oxidecomputer/humility
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
oxidecomputer/humility#737 · 1 comentario ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 65/100
oxidecomputer/humility#730 · 1 comentario ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 42/100
oxidecomputer/humility#723 · 1 comentario ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
oxidecomputer/humility#705 · 12 comentarios ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
oxidecomputer/humility#678 · 1 comentario ·
Todos los issues de oxidecomputer/humility
Issues similares
-
area: compat area: parsing bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
reubeno/brush#1526 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
OFN writer emits `DocIRI` as a bare IRI, which becomes a version IRI or a parse error on re-readAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
phillord/horned-owl#338 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
type/bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
stackabletech/operator-rs#1301 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
jmcnamara/rust_xlsxwriter#205 · 4 comentarios ·