Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

WrappedObject/Object/NativeMethod aren't genuinely Sync

Abierto
  • ¿Algo no está bien?
#366 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Refactorización
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
rust
Área
operating-systems

Línea de trabajo

Start by reading the linked comment on #324 and tracing the relationships among NativeMethod, Object, WrappedObject, and NoSendInterpreter. Compare the three approaches described in the issue, including how interpreter-specific closures and object transfer should work. Done means the chosen design makes the Send and Sync guarantees accurate without losing support for non-Send native methods.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

This issue is born out of my comment on #324 about NativeMethod.

NativeMethod does not have type bounds enforcing that its contained closure is Send. Therefore Object and WrappedObject can't be Send either.

To avoid cluttering #324 - there's actually a reasonably straightforward fix for FixedRegisters, I'm going to continue the NativeMethod discussion here.

Firstly, should we allow non-Send NativeMethods for NoSendInterpreter? My feeling is yes, we should. It stands to reason that if you're using a non-Send interpreter you have a good reason for that, so we should accept closures that work with the types you're using.

Secondly, how?

The fact that WrappedObject can contain a NativeMethod (via Object), and NativeMethod refers to WrappedObject means there's effectively a cycle in type references.

I can think of three ways:

  1. Deal with horrendous generic types and bounds - I don't think there's a straightforward way of limiting the generic types, they'll touch pretty much every other type in the crate. I'm still not entirely sure it actually is even possible, because of the cycle in type references.
  2. Remove NativeMethod from Object completely. Then Object is effectively AmlObject, we'd need a NonAmlObject to hold NativeMethod and anything else we think of in future. Plus wrapper types that could hold either.
    • This would allow objects to be passed between two different interpreters, as they could be now.
  3. Turn NativeMethod into a kind of index - perhaps an AmlName, or even just an integer - then store the actual closures in a map in the namespace.
    • In this case, objects are less easily passed between two interpreters, as the NativeMethods would be different.
    • I haven't fully worked out how any reference counting would work to ensure the closures are freed when needed, but it seems tractable.

I'd probably go for option 3, since it reduces the distinction between NativeMethod and other object types. This hopefully makes it less likely we'd introduce bugs related to it in future.

But thoughts from @IsaacWoods and anyone else interested are most welcome.

Lenguaje dominante
Rust
Estrellas
248
Forks
95
Merge medio
3 d 14 h
PR fusionados (30 d)
9

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

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de rust-osdev/acpi

Todos los issues de rust-osdev/acpi

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.