Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

WrappedObject/Object/NativeMethod aren't genuinely Sync

オープン
  • 何か問題がありますか？
#366 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
リファクタリング
明瞭さ
説明が足りない
活発さ
活発
技術スタック
rust
領域
operating-systems

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Rust
スター
248
フォーク
95
平均マージ
3日 14時間
マージ済み PR（30日）
9

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

rust-osdev/acpi のほかの issue

rust-osdev/acpi の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。