`WaitChannel` design

[efenniht]

WaitChannel 에 대해서 고민해봤는데, 이런 형태의 디자인이 과연 올바른 지 궁금합니다. @jeehoonkang

• 원래 xv6 는 애초에 wait channel 이라는 type 이 없고 서로 다른 변수에 대한 주소를 wait channel identifier로 사용합니다. Make wait channel non-zero-sized #236 에 의해 WaitChannel 을 들고 있는 타입은 크기가 커집니다. 그렇다고 WaitChannel<T> 같은 타입은 더 이상한 것 같습니다.
• WaitChannel 은 주소가 wait 대상의 identifier 가 되므로 move 되면 스레드를 깨워도 일어나지 않거나 이상한 스레드가 깨는 등 의도되지 않은 일이 일어날 수 있습니다. 따라서 올바른 API는 sleep(self: Pin<&mut Self>, ...) 이 되어야 합니다. 다만 이것은 safety invariant 는 아니므로 주석만 쓰고 넘길 수도 있습니다.
• Redox 의 구현은 해당 채널을 대기하고 있는 스레드를 queue 에 넣어서 WaitChannel 의 멤버로 들고 있습니다. 이러면 channel 이 move 되어도 문제가 없습니다.

어떻게 수정하는 것이 옳을까요?

1. 현상 유지
2. Pin 넣고 타입 대공사
3. Redox 처럼 수정하기

Originally posted by @efenniht in #236 (comment)

[jeehoonkang]

저는 2가 어떨까 합니다. 되도록 xv6의 의도를 따라가면서도 safe api를 지원하면 좋겠어서 그렇습니다. 1은 unsafe, 3은 xv6의 의도와 다름.

[coolofficials]

혹시 급한(쓰시는 논문에 중요하게 다룰 예정인) refactoring point가 아니라면 시험 이후에 제가 좀 봐도 괜찮을까요? @efenniht

이유는

1. Proc.rs와의 관련성
2. Pin API의 사용
   입니다.

[efenniht]

혹시 급한(쓰시는 논문에 중요하게 다룰 예정인) refactoring point가 아니라면 시험 이후에 제가 좀 봐도 괜찮을까요? @efenniht

이유는

1. Proc.rs와의 관련성

2. Pin API의 사용
   입니다.

네, 부탁드립니다 🙏

[coolofficials]

현재는 WaitChannel의 move가 발생하는 부분이 존재하지 않기 때문에 이 이슈는 후순위로 미루고 proc.rs 의 다른 refactoring point를 먼저 진행하도록 하겠습니다. (현재 발생하지 않은 문제에 대한 예방책입니다.)

[jeehoonkang]

@travis1829 혹시 진행중인 PR이 있나요?

[travis1829]

@travis1829 혹시 진행중인 PR이 있나요?

아직 PR은 없습니다!

[travis1829]

WaitChannel을 어떻게 바꾸면 좋을지에 대해 의문사항이 좀 있어서 comment을 답니다.

• Pin API가 의미가 있으려면, WaitChannel API (ex: WaitChannel::new())가 WaitChannel은 노출시키지 않고 Pin<&WaitChannel>만을 노출시켜야 되는 것 같습니다. 다만, 이러면 WaitChannel 자체는 어디에 저장을 시키느냐가 문제인 것 같습니다.
  • 현재는 WaitChannel을 Pipe나 Proc 등 struct의 field로 저장하므로 WaitChannel이 노출되고, WaitChannel 또는 그 struct 자체가 move되지 않도록 알아서 조심해야 됩니다.
  • 일반적으로는 WaitChannel자체는 heap에 저장하고 WaitChannel::new()는 Pin<&WaitChannel>을 리턴하게 하면 되겠지만 kernel 내부에서는 heap의 개념이 없으니, WaitChannel 자체는 그냥 static한 array에 저장을 하면 어떨지 제안드립니다. (다만, 이러면 xv6랑은 달라지기도 하고, 각각의 WaitChannel을 어떤 index에 저장할지를 macro등으로 미리 결정해야합니다.)
• 훨씬 더 간단한 방법으로는, 그냥 macro로 각각의 WaitChannel에 usize id를 assign해주면 나중에 move되든 어떻게 되든 상관이 없어지게 됩니다. 다만, 이것도 xv6랑 달라지게 되는 건 마찬가지입니다.

참고: 혹시, 제가 Pin API에 대해 잘못 이해하고 있는게 있다면 알려주세요.

[jeehoonkang]

WaitChannel과 이를 포함하는 struct (Pipe, Proc) 모두 안움직이도록 강제할 수도 있을까요? 제가 Pin에 대해 까먹었는데 가령 Pin<Proc> 같은 타입을 쓰면 해결되는지 궁금합니다.

[travis1829]

예, API가 Pipe나 Proc자체는 노출시키지 않고 (그러면서 어딘가에는 저장을 하고), 그 대신 Pin<&Pipe>나 Pin<&Proc>만 노출시키도록 변경하면 모두 안 움직이게 강제할 수 있습니다! 다만, 이러면 타입 대공사의 규모가 훨씬 커질것 같습니다.

EDIT: 다만, 애초에 Pipe나 Proc이 WaitChannel을 소유하지 않고 Pin<&WaitChannel>만을 가지고 있다면, Proc나 Pipe이 move하게 되더라도 WaitChannel은 문제없이 사용 가능합니다.

[jeehoonkang]

• (편의상 WC라고 하게씁니다) WC를 만들고 이동하는 것까지 허용하되, 누군가가 거기서 wait하고 있으면 더이상 이동할 수 없도록 API를 디자인할 수도있지 않을가요?
• 저는 일단 xv6의 디자인을 좀 따라가보는게 어떨까 합니다. 나중에 가면 waitlist를 구현하기도 할텐데 (redox처럼) waitlist가 없는 구현도 필요하긴 할것 같아서요
• 구체적으로 어떻게 API를 디자인해야할지 고민이 필요한데, 제가 어렴풋이 기억하기로 이문제의 해답중에 Pin이 꼭 있어야 할겁니다. 근데 제가 Pin에 대해 좀 까먹어서 그런데 혹시 API 문서 보시고 간단히 요약해서 정리해주실 수 있으시면 감사드리겠습니다.