Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

WrappedObject/Object/NativeMethod aren't genuinely Sync

Đang mở
  • Có gì không ổn?
#366 3 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tái cấu trúc
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
rust
Lĩnh vực
operating-systems

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Rust
Star
248
Fork
95
Merge trung bình
3 ngày 14 giờ
Pull request đã merge (30 ngày)
9

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của rust-osdev/acpi

Tất cả issue của rust-osdev/acpi

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.