@rfcbot fcp 병합

팀원 @withoutboats 가 이를 병합할 것을 제안했습니다. 다음 단계는 태그가 지정된 나머지 팀원이 검토하는 것입니다.

• [x] @센트릴
• [x] @cramertj
• [x] @eddyb
• [x] @joshtriplett
• [x] @nikomatsakis
• [ ] @pnkfelix
• [x] @scottmcm
• [x] @withoutboats

우려 사항:

• 구현-작업-차단-안정화 는 https://github.com/rust-lang/rust/issues/62149#issuecomment -517418610에 의해 해결되었습니다.

과반수의 검토자가 승인하면(최대 2개의 승인이 미결 상태임) 최종 의견 수렴 기간이 시작됩니다. 이 프로세스의 어느 시점에서도 제기되지 않은 주요 문제를 발견하면 알려주세요!

태그가 지정된 팀 구성원이 나에게 줄 수 있는 명령에 대한 정보는 이 문서 를 참조하십시오.

(위 리포트에 기존 차단제만 등록하면 미끄러지지 않습니다)

@rfcbot 우려 구현-작업-차단-안정화

팀원이 ...이를 병합 하도록 제안했습니다.

어떻게 Github 이슈를 병합할 수 있습니까(풀 리퀘스트가 아님)?

@vi 봇은 약간

와우, 종합적인 요약 감사합니다! 나는 단지 접선적으로 따랐지만 당신이 모든 것의 정상에 있다고 완전히 확신합니다.

@rfcbot이 검토했습니다.

안정화 차단기에 "AsyncAwait-Unclear 문제 분류"를 명시적으로 추가(및/또는 이에 대한 우려 등록)할 수 있습니까?

나는 중요하다고 생각하는 https://github.com/rust-lang/rust/issues/60414 를 가지고 있으며(분명히 내 버그입니다. p), 적어도 안정화 전에 명시적으로 연기하고 싶습니다. :)

Rust 팀이 이 기능에 쏟은 노력에 대해 커뮤니티에 감사를 표하고 싶습니다! 많은 설계, 토론, 의사소통의 단절이 있었지만 적어도 저와 많은 다른 사람들은 이 모든 것을 통해 우리가 Rust를 위한 최상의 솔루션을 찾았다고 확신합니다. :따다:

(즉, 미래 가능성에서 완료 기반 및 비동기 취소 시스템 API에 대한 브리징 문제에 대한 언급을 보고 싶습니다. TL;DR 여전히 소유 버퍼를 전달해야 합니다. 라이브러리 문제이지만 하나 언급하면서.)

또한 완성 기반 API의 문제에 대한 언급을 보고 싶습니다. (컨텍스트는 이 내부 스레드 참조) IOCP 및 io_uring 도입을 고려할 때 Linux에서 The Way for async IO가 될 수 있으므로 이를 처리하기 위한 명확한 방법을 갖는 것이 중요하다고 생각합니다. IIUC 가상의 비동기 드롭 아이디어는 안전하게 구현될 수 없으며 소유 버퍼를 전달하는 것은 덜 편리하고 잠재적으로 성능이 떨어질 것입니다(예: 더 나쁜 지역 또는 추가 복사본으로 인해).

@newpavlov 나는 Fuchsia에 대해 비슷한 것을 구현했으며 비동기 드롭 없이 완전히 가능합니다. 이를 수행하는 몇 가지 다른 경로가 있습니다. 예를 들어 리소스를 획득할 때 이전 리소스에서 일부 정리 작업이 완료될 때까지 기다려야 하는 리소스 풀링을 사용하는 경우입니다. 현재 futures API는 프로덕션 시스템에서 이러한 문제를 효과적으로 해결하는 데 사용될 수 있고 사용되어 왔습니다.

다만, 이 문제는 이미 안정화된 futures API 설계와 직교하는 async/await의 안정화에 관한 것이다. 추가 질문을 하거나 future-rs repo에 대한 토론을 위해 문제를 여십시오.

@Ekleog

안정화 차단기에 "AsyncAwait-Unclear 문제 분류"를 명시적으로 추가(및/또는 이에 대한 우려 등록)할 수 있습니까?

네, 매주 하고 있는 일입니다. 해당 특정 문제(#60414)를 WRT하는 것이 중요하다고 생각하고 수정되었으면 좋겠지만 특히 -> impl Trait 에서 이미 관찰할 수 있기 때문에 안정화를 차단해야 하는지 여부를 아직 결정할 수 없었습니다

@cramertj 감사합니다! #60414 의 문제는 기본적으로 "지금 오류가 정말 빨리 발생할 수 있습니다"라고 생각합니다. 반면 -> impl Trait 경우 이전에는 아무도 눈치채지 못한 것처럼 보입니다. 어쨌든 지연되면 괜찮습니다. 일부 문제 해야 할 것입니다 :) (FWIW 한 곳에서 () 와 다른 곳에서 T::Assoc 를 모두 반환하는 함수의 자연 코드에서 발생하여 IIRC에서 컴파일할 수 없었습니다. #60414를 연 이후로 코드를 확인하지 않았으므로 아마도 내 기억이 틀릴 수 있습니다)

@Ekleog 네 이해가 됩니다! 나는 그것이 고통스러운 이유를 확실히 알 수 있습니다. 특정 문제에 대해 더 자세히 알아보기 위해 zulip 스트림 을 만들었습니다.

편집: 신경 쓰지 마세요. 1.38 목표를 놓쳤습니다.

@cramertj

이를 수행하는 몇 가지 다른 경로가 있습니다. 예를 들어 리소스를 획득할 때 이전 리소스에서 일부 정리 작업이 완료될 때까지 기다려야 하는 리소스 풀링을 사용하는 경우입니다.

버퍼를 미래 상태의 일부로 유지하는 것과 비교하여 덜 효율적이지 않습니까? 내 주요 관심사는 현재 디자인이 비용이 전혀 들지 않고( async 추상화를 삭제하여 더 효율적인 코드를 만들 수 있다는 의미에서) 완성 기반 API에서 인체 공학적이지 않다는 것입니다. 그것을 고칠 명확한 방법이 없습니다. 딱히 뽐낼 정도는 아니지만, 그런 디자인의 미비함을 잊지 않고 OP에서 언급해달라는 요청이 중요하다고 생각합니다.

@공작

물론 lang 팀은 이것을 나보다 더 잘 판단할 수 있지만 안정적인 구현을 위해 1.38 로 연기하는 것이 훨씬 더 합리적으로 보입니다.

이 문제는 1.38을 대상으로 합니다. 설명의 첫 번째 줄을 참조하십시오.

@huxi 감사합니다, 나는 그것을 놓쳤습니다. 내 댓글을 수정했습니다.

@newpavlov

버퍼를 미래 상태의 일부로 유지하는 것과 비교하여 덜 효율적이지 않습니까? 내 주요 관심사는 현재 디자인이 비용이 전혀 들지 않고(비동기 추상화를 삭제하여 보다 효율적인 코드를 생성할 수 있다는 의미에서) 완성 기반 API에서 인체공학적이지 않고 수정을 위한 명확한 방법이 없다는 것입니다. 그것. 딱히 뽐낼 정도는 아니지만, 그런 디자인의 미비함을 잊지 않고 OP에서 언급해달라는 요청이 중요하다고 생각합니다.

아니요, 반드시 그런 것은 아니지만 비동기/대기의 안정화와 관련이 없기 때문에 이 논의를 별도의 스레드에 있는 문제로 옮기겠습니다.

(즉, 미래 가능성에서 완료 기반 및 비동기 취소 시스템 API에 대한 브리징 문제에 대한 언급을 보고 싶습니다. TL;DR 여전히 소유 버퍼를 전달해야 합니다. 라이브러리 문제이지만 하나 언급하면서.)

또한 완성 기반 API의 문제에 대한 언급을 보고 싶습니다. (컨텍스트는 이 내부 스레드 참조) IOCP 및 Linux에서 비동기 IO를 위한 방법이 될 수 있는 io_uring의 도입을 고려할 때 이를 처리하기 위한 명확한 방법을 갖는 것이 중요하다고 생각합니다.

이 문제 공간에서 API 설계에 대해 논의하는 것이 주제에서 벗어난다는 Taylor의 의견에 동의하지만 비동기/대기 안정화와 관련된 이러한 주석(및 일반적으로 io_uring에 대한 이 논의)의 한 가지 특정 측면을 다루고 싶습니다. 타이밍.

io_uring은 2019 년 올해 Linux에 출시될 인터페이스입니다. Rust 프로젝트는 4년 전인 2015년부터 미래 추상화 작업을 해왔습니다. 완성 기반 API에 기반한 설문 조사를 선호하는 근본적인 선택은 2015년과 2016년에 발생했습니다. 2015년 RustCamp에서 Carl Lerche는 기본 IO 추상화인 mio에서 왜 그런 선택을 했는지 이야기했습니다. 2016년 이 블로그 게시물에서 Aaron Turon은 더 높은 수준의 추상화를 생성할 때의 이점에 대해 이야기했습니다. 이러한 결정은 오래전에 내려진 것이며 그것들이 없었다면 지금의 시점에 도달할 수 없었을 것입니다.

기본 미래 모델을 재검토해야 한다는 제안은 3~4년 전 상태로 돌아가서 그 시점에서 다시 시작해야 한다는 제안입니다. Aaron이 설명한 것처럼 더 높은 수준의 기본 요소에 대한 오버헤드를 도입하지 않고 어떤 종류의 추상화가 완료 기반 IO 모델을 다룰 수 있습니까? 사용자가 async/await 방식으로 "일반 Rust + 사소한 주석"을 작성할 수 있도록 하는 구문에 해당 모델을 어떻게 매핑할까요? 핀이 있는 상태 머신에 대해 수행한 것처럼 이를 메모리 모델에 통합하는 것을 어떻게 처리할 수 있습니까? 이러한 질문에 대한 답변을 제공하는 것은 이 스레드의 주제에서 벗어납니다. 요점은 그들에게 대답하고 정답을 증명하는 것이 일이라는 것입니다. 지금까지 서로 다른 기여자들 사이의 견고한 10년의 노동력에 해당하는 것은 다시 다시 수행되어야 할 것입니다.

녹의 목표는 사람들이 사용할 수있는 제품, 우리가 제공해야하는 수단을 제공하는 것입니다. 내년에 큰 일이 될 수 있는 미래를 내다보고 이를 통합하기 위해 설계 프로세스를 다시 시작하기 위해 항상 멈출 수는 없습니다. 우리는 우리가 처한 상황에 따라 최선을 다합니다. 분명히 큰 일을 간신히 놓친 것 같은 기분이 들게 하는 것은 실망스러울 수 있지만, 현재로서는 최선의 결과가 무엇인지에 대한 전체 보기도 없습니다. io_uring을 처리하기 위해 b) io_uring이 전체 생태계에서 얼마나 중요한지. 이것을 기준으로 4년의 작업을 되돌릴 수는 없습니다.

이미 유사한, 아마도 훨씬 더 심각한 Rust의 한계가 다른 공간에 있습니다. 지난 가을에 Nick Fitzgerald와 함께 본 wasm GC 통합을 강조하고 싶습니다. wasm에서 관리 객체를 처리하기 위한 계획은 본질적으로 메모리 공간을 분할하여 관리되지 않는 객체와 별도의 주소 공간에 존재하도록 하는 것입니다(실제로 언젠가는 많은 개별 주소 공간에). Rust의 메모리 모델은 단순히 별도의 주소 공간을 처리하도록 설계되지 않았으며 오늘날 힙 메모리를 처리하는 안전하지 않은 코드는 주소 공간이 1개만 있다고 가정합니다. 우리는 파괴적이고 기술적으로는 파괴적이지 않지만 극도로 파괴적인 기술 솔루션을 모두 스케치했지만 앞으로 나아갈 가능성이 가장 높은 경로는 우리의 wasm GC 스토리가 완벽하게 최적 이 아닐 수도 있다는 것을 받아들이는 것입니다. 왜냐하면 우리는 Rust의 한계를 다음과 같이 다루고 있기 때문입니다. 그것은 존재합니다.

여기서 안정화하고 있는 흥미로운 측면은 안전한 코드에서 사용할 수 있는 자체 참조 구조체를 만들고 있다는 것입니다. 이것을 흥미롭게 만드는 것은 Pin<&mut SelfReferentialGenerator> 에서 전체 생성기 상태를 가리키는 변경 가능한 참조( Pin 필드로 저장됨)가 있고 해당 상태를 가리키는 포인터가 있다는 것입니다. 국가의 다른 부분으로. 내부 포인터는 변경 가능한 참조로 별칭 을 지정합니다!

내가 아는 한 변경 가능한 참조는 다른 필드에 대한 포인터가 가리키는 메모리 부분에 실제로 액세스하는 데 사용되지 않습니다. (특히 clone 메서드가 없거나 자체 참조 포인터 이외의 다른 포인터를 사용하여 포인터 필드를 읽는 방법이 없습니다.) 그래도 이것은 핵심 생태계의 다른 무엇보다 특히 Rustc 자체와 함께 제공되는 다른 모든 것입니다. 우리가 여기에서 타고 있는 "라인"은 매우 얇아지고 있으며 변경 가능한 참조를 기반으로 하려는 이러한 모든 멋진 최적화를 잃지 않도록 주의해야 합니다.

이 때문에 거의 우리가 특히,이 시점에서 그것에 대해 할 수있는 아마 Pin 이미 안정적이지만, 나는 가치가 앨리어싱이 허용되는이 규칙이있는 상당히 복잡한 끝날 어떤 것을 가리키는 느낌 그렇지 않습니다. Stacked Borrows가 복잡하다고 생각했다면 상황이 악화될 것에 대비하십시오.

참조 https://github.com/rust-lang/unsafe-code-guidelines/issues/148

내가 아는 한 변경 가능한 참조는 다른 필드에 대한 포인터가 가리키는 메모리 부분에 실제로 액세스하는 데 사용되지 않습니다.

사람들은 이러한 모든 코루틴 유형이 Debug 구현하도록 하는 것에 대해 이야기했습니다. 이 대화는 또한 인쇄를 디버그하기에 안전한지 확인하기 위해 안전하지 않은 코드 지침을 통합해야 하는 것처럼 들립니다.

사람들은 이러한 모든 코루틴 유형이 디버그를 구현하도록 하는 것에 대해 이야기했습니다. 이 대화는 디버그 인쇄에 안전한지 확인하기 위해 안전하지 않은 코드 지침도 통합해야 하는 것처럼 들립니다.

물론. 자체 참조 필드를 인쇄하는 경우 이러한 Debug 구현은 생성기 내부의 MIR 수준 참조 기반 최적화를 금지할 수 있습니다.

차단기에 관한 업데이트:

두 가지 높은 수준의 차단기는 모두 큰 발전을 이루었고 실제로 둘 다 끝낼 수도 있습니다(?). 이에 대한 @cramertj @tmandry 및 @nikomatsakis의 자세한 정보는 다음 과 같습니다 .

• 다중 수명 문제는 #61775로 수정되어야 합니다.
• 크기 문제는 더 모호합니다. 항상 더 많은 최적화 작업이 수행될 것이지만 명백한 기하급수적 증가를 피하는 낮은 교수형 결과가 대부분 해결되었다고 생각합니까?

이로 인해 이 기능을 안정화하는 데 있어 문서 및 테스트가 주요 장애물로 남아 있습니다. @Centril 은 이 기능이 제대로 테스트되지 않았거나 충분히 다듬어지지 않았다는 우려를 지속적으로 표명했습니다. @Centril 이 기능을 안정화하기 위해 확인할 수 있는 특정 문제를 열거한 곳이 있습니까?

문서를 운전하는 사람이 있는지 확실하지 않습니다. 책, 참조 등의 트리 내 문서를 개선하는 데 집중하고 싶은 사람은 훌륭한 서비스를 제공할 것입니다! future repo 또는 areweasyncyet과 같은 외부 문서에는 약간의 추가 시간이 있습니다.

오늘부터 베타가 종료될 때까지 6주가 남았습니다. 따라서 1.38이 미끄러지지 않을 것이라고 확신하기 위해 이러한 작업을 완료하는 데 4주(8월 1일까지)가 있다고 가정해 보겠습니다.

크기 문제는 더 모호합니다. 항상 더 많은 최적화 작업이 수행될 것이지만 명백한 기하급수적 증가를 피하는 낮은 교수형 결과가 대부분 해결되었다고 생각합니까?

나는 그렇게 생각하며 최근에 다른 사람들도 문을 닫았습니다. 그러나 다른 차단 문제가 있습니다 .

@Centril 이 기능을 안정화하기 위해 확인할 수 있는 특정 문제를 열거한 곳이 있습니까?

테스트하려는 항목 목록이 포함된 보관용 문서가 있으며 https://github.com/rust-lang/rust/issues/62121이 있습니다. 그 외에는 최대한 빨리 테스트되지 않았다고 생각되는 영역을 재검토하려고 노력할 것입니다. 즉, 일부 영역은 이제 꽤 잘 테스트되었습니다.

책, 참조 등의 트리 내 문서를 개선하는 데 집중하고 싶은 사람은 훌륭한 서비스를 제공할 것입니다!

물론; 참조에 대한 PR을 검토하게 되어 기쁩니다. 또한 cc @ehuss.

나는 또한 async unsafe fn 를 MVP에서 자체 기능 게이트로 옮기고 싶습니다. 왜냐하면 a) 거의 사용되지 않았고, b) 특별히 잘 테스트되지 않았으며, c) .await 포인트는 unsafe { ... } 를 쓰는 곳이 아니며 "누설 구현 POV"에서는 이해할 수 있지만 효과 POV에서는 그다지 많지 않습니다. d) 논의가 거의 없었고 RFC에 포함되지 않았습니다. 이 보고서도 아니고 e) const fn 로 이 작업을 수행했으며 제대로 작동했습니다. (피처 게이팅 PR을 작성할 수 있습니다)

나는 async unsafe fn 을 불안정하게 하는 것은 괜찮지

async unsafe fn 를 고유한 기능 게이트로 이동하기 위해 https://github.com/rust-lang/rust/issues/62500 을 만들고 차단기로 나열했습니다. 적절한 추적 문제도 만들어야 할 것 같습니다.

나는 우리가 async unsafe fn 에 대해 다른 디자인에 도달할 것인지에 대해 매우 회의적이며 초기 안정화 단계에 포함하지 않기로 한 결정에 놀랐습니다. 나는 안전하지 않은 async fn 을 여러 개 작성했으며 async fn really_this_function_is_unsafe() 또는 무엇인가를 만들 것입니다. 이것은 Rust 사용자가 unsafe { ... } 를 호출해야 하는 함수를 정의할 수 있다는 면에서 기본적인 기대치의 회귀처럼 보입니다. 또 다른 기능 게이트는 async / await 가 미완성이라는 인상에 기여할 것입니다.

@cramertj 는 우리가 논의해야 할 것 같습니다! 이 추적 문제가 너무 과부하되지 않도록 하기 위해 Zulip 주제를 만들었습니다 .

향후 크기에 대해서는 모든 await 포인트에 영향을 미치는 경우가 최적화됩니다. 내가 아는 마지막 남은 문제는 #59087로, 기다리기 전에 미래를 빌릴 경우 해당 미래에 할당된 크기가 두 배가 될 수 있습니다. 이것은 매우 불행하지만 여전히 우리가 이전에 있었던 것보다 훨씬 낫습니다.

나는 그 문제를 해결하는 방법에 대한 아이디어가 있지만 이것이 내가 생각하는 것보다 훨씬 일반적이지 않다면 안정적인 MVP를 방해해서는 안 됩니다.

즉, 이러한 최적화가 Fuchsia에 미치는 영향을 살펴봐야 합니다(잠시 차단되었지만 오늘이나 내일 해결될 예정임). 더 많은 사례를 발견할 가능성이 높으며 차단해야 하는 사례가 있는지 결정해야 합니다.

@cramertj (알림: async/await를 사용하고 최대한 빨리 안정화하기를 원합니다.) 귀하의 주장은 적절한 실험과 생각 없이 바로 지금 async unsafe 을 안정화하기 위한 것이 아니라 async/await의 안정화를 지연하기 위한 주장처럼 들립니다.

특히 RFC에 포함되지 않았으므로 이러한 방식으로 강제 종료되면 잠재적으로 또 다른 "인수 위치의 암시적 특성"을 유발할 수 있습니다.

[여기서 논의할 가치가 없는 참고 사항: "또 다른 기능 게이트는 async/await가 완료되지 않은 인상에 기여할 것입니다."에 대해, 저는 async/await를 사용하는 몇 시간마다 버그를 발견했으며, 소수에 의해 퍼졌습니다. Rustc 팀이 문제를 수정하는 데 합법적으로 필요한 몇 달이고, 그것이 내가 아직 미완성이라고 말하게 만드는 것입니다. 마지막 하나는 며칠 전에 수정되었으며 새로운 Rustc로 코드를 다시 컴파일하려고 할 때 다른 하나를 발견하지 않기를 바랍니다. 하지만…]

당신의 주장은 적절한 실험과 생각 없이 지금 당장 불안정한 비동기를 안정화하기 위한 것이 아니라 async/await의 안정화를 지연시키기 위한 주장처럼 들립니다.

아니요, 그것에 대한 주장이 아닙니다. async unsafe 이 준비가 되었다고 생각하며 다른 디자인은 상상할 수 없습니다. 이 초기 릴리스에 포함하지 않는 것은 부정적인 결과만 있을 뿐이라고 생각합니다. async / await 를 전체적으로 지연하거나 구체적으로 async unsafe 를 지연하는 것이 더 나은 결과를 낳을 것이라고는 생각하지 않습니다.

다른 디자인은 상상할 수 없습니다

복잡한 확장이 확실히 필요한 대안 디자인: async unsafe fn 은 unsafe 가 아니라 .await call() 입니다. async fn 가 호출되고 impl Future 생성되는 지점에서 _안전하지 않은 것은 아무것도 할 수 없다는 이유입니다. 이 단계는 데이터를 구조체에 넣는 것뿐입니다(사실상 모든 async fn 는 호출할 const ). 실제 안전하지 못한 점은 poll 미래를 전진시키는 것입니다.

(임호, unsafe 가 즉각적이면 unsafe async fn 가 더 합리적이고 unsafe 가 지연되면 async unsafe fn 가 더 합리적입니다.)

물론, 우리는 결코 말할 수있는 방법을 얻을 수없는 경우 예를 들어 unsafe Future 모든 방법 경우 Future 당시 "리프팅"전화를 안전하지 unsafe 의 창조에 impl Future , 그리고 그 unsafe 의 계약은 결과적인 미래를 안전한 방법으로 사용하는 것입니다. 그러나 async 블록 unsafe fn os_stuff() -> impl Future { async { .. } } 수동으로 "디슈가링"하여 unsafe async fn 없이도 거의 간단하게 수행할 수 있습니다.

그러나 그 위에 poll ing이 시작되면 생성 시 보유할 필요가 없는 불변량을 보유해야 하는 불변량을 갖는 방법이 실제로 존재하는지에 대한 질문이 있습니다. unsafe 생성자를 안전한 유형으로 사용하는 것은 Rust의 일반적인 패턴입니다(예: Vec::from_raw_parts ). 그러나 핵심은 구성 후에 유형을 오용할 수 _없습니다. unsafe 범위가 끝났습니다. 이러한 불안전성의 범위는 Rust가 보장하는 핵심입니다. 폴링 방법/시기에 대한 요구 사항과 함께 안전한 impl Future 상자를 만드는 unsafe async fn 를 도입한 다음 안전한 코드에 전달하면 해당 안전한 코드가 갑자기 안전하지 않은 장벽 안에 있게 됩니다. 그리고 이것은 _some_ 외부 결합기를 통과할 가능성이 높기 때문에 즉시 기다리는 것 이외의 다른 방식으로 이 미래를 사용하자마자 일어날 가능성이 _매우_ 높습니다.

TL;DR은 async unsafe fn 를 안정화하기 전에 적절하게 논의해야 하는 구석이 분명히 있다는 것입니다. 특히 const Trait 의 방향이 잠재적으로 도입될 가능성이 있습니다(저는 블로그 초안이 있습니다. fn -modifying 키워드를 사용하여 이것을 "약한 '효과' 시스템"으로 일반화하는 방법에 대해 게시). 그러나 unsafe async fn 는 안정화를 위해 unsafe 의 "주문"/"포지셔닝"에 대해 실제로 충분히 명확할 수 있습니다.

나는 효과 기반 unsafe Future 특성이 오늘날 우리가 언어나 컴파일러로 표현하는 방법을 알고 있는 어떤 것도 도달할 수 없을 뿐만 아니라 추가 효과로 인해 궁극적으로 더 나쁜 디자인이 될 것이라고 믿습니다. 결합자가 필요로 하는 다형성.

async fn이 호출되고 impl Future를 생성하는 지점에서는 안전하지 않은 작업을 수행할 수 없습니다. 이 단계는 데이터를 구조체에 채우는 것뿐입니다(사실상 모든 비동기 fn은 호출할 const입니다). 실제 불안요소는 여론조사로 미래를 앞당기는 것이다.

async fn 는 .await ed가 되기 전에 사용자 코드를 실행할 수 없기 때문에 정의되지 않은 동작은 .await 가 호출될 때까지 지연될 수 있습니다. 하지만 UB의 포인트와 unsafe ty의 포인트 사이에는 중요한 차이가 있다고 생각합니다. unsafe ty의 실제 요점은 위반되는 불변의 결과가 UB를 유발하지 않더라도 API 작성자가 정적으로 검증할 수 없는 일련의 불변이 충족된다고 사용자가 약속해야 한다고 결정한 곳입니다. 나중에 다른 안전한 코드가 나올 때까지. 이것의 한 가지 일반적인 예는 안전한 방법(정확히 이것이 무엇인지)으로 특성을 구현하는 값을 생성하는 unsafe 함수입니다. 예를 들어 Visitor unsafe 불변에 의존하는 구현의 Visitor -trait-implementing 유형이 유형을 구성하기 위해 unsafe 를 요구함으로써 제대로 사용될 수 있는지 확인하기 위해 이것이 사용되는 것을 보았습니다. 다른 예에는 slice::from_raw_parts 와 같은 것들이 포함됩니다. 이는 자체적으로 UB(유형 유효성 불변은 제외)를 발생시키지 않지만 결과 슬라이스에 대한 액세스는 발생합니다.

async unsafe fn 가 여기에서 독특하거나 흥미로운 사례를 나타낸다고 생각하지 않습니다. unsafe 요구하여 안전한 인터페이스 뒤에서 unsafe 동작을 수행하는 잘 정립된 패턴을 따릅니다. 건설자.

@cramertj 당신이 이것에 대해 논쟁을 해야 한다는 사실(그리고 나는 현재 해결책이 나쁜 해결책이라고 생각하거나 더 나은 아이디어가 있다고 제안하는 것이 아닙니다)은 나에게 이 논쟁이 녹을 걱정하는 사람들이 따라야 할 장소: RFC 저장소.

참고로 읽어보기에서 인용한 내용은 다음과 같습니다.

[...]인 경우 이 프로세스를 따라야 합니다.

• 버그수정이 아닌 언어에 대한 의미 또는 구문 변경.
• [... 또한 인용되지 않은 것들]

현재 디자인이 변경될 것이라고 말하는 것이 아닙니다. 사실, 몇 분 동안 생각해보면 그것이 내가 생각할 수 있는 최고의 디자인일 것 같다는 생각이 듭니다. 그러나 프로세스는 우리의 믿음이 Rust에 대한 위험이 되는 것을 피할 수 있게 해주며, RFC 저장소를 따르지만 여기의 프로세스를 따르지 않음으로써 모든 단일 문제를 읽지 않는 많은 사람들의 지혜를 놓치고 있습니다.

때로는 프로세스를 따르지 않는 것이 합리적일 수 있습니다. 여기서 나는 FCP 지연의 약 2주를 피하기 위해 프로세스를 무시하는 것을 정당화할 시급함을 볼 수 없습니다.

따라서 Rust가 자체 readme에서 제공하는 약속에 대해 커뮤니티에 정직하게 하고 최소한 허용되는 RFC가 있고 야생에서 더 많이 사용할 수 있을 때까지 해당 기능을 기능 게이트 아래에 유지하십시오. 전체 async/await 기능 게이트이든 아니면 단지 unsafe-async 기능 게이트이든 상관하지 않지만 (AFAIK) async-wg 이상으로 거의 사용되지 않고 거의 알려지지 않은 것을 안정화하지 마십시오. 전체 커뮤니티.

나는 책의 참고 자료에 첫 번째 패스를 쓰고 있습니다. 그 과정에서 async-await RFC가 ? 연산자의 동작이 아직 결정되지 않았다고 말합니다. 그러나 비동기 블록( playground )에서는 잘 작동하는 것 같습니다. 이를 별도의 기능 게이트로 옮겨야 합니까? 아니면 어느 시점에서 해결되었습니까? 안정화 보고서에서는 못 봤는데 놓쳤을 수도 있겠네요.

(저도 Zulip에서 이 질문

예, return , break , continue 등의 행동과 함께 논의되고 해결되었습니다. 알. 모두 "유일한 가능한 일"을 수행하고 클로저 내부에서와 같이 동작합니다.

let f = unsafe { || {...} }; 는 호출하기에 안전하며 IIRC는 unsafe 를 클로저 내부로 이동하는 것과 같습니다.
unsafe fn foo() -> impl Fn() { || {...} } 입니다.

이것은 나에게 " unsafe 범위를 떠난 후 안전하지 않은 일이 발생합니다"에 대한 선례입니다.

다른 곳도 마찬가지입니다. 이전에 지적했듯이 unsafe 는 항상 잠재적인 UB가 있는 위치가 아닙니다. 예시:

    let mut vec: Vec<u32> = Vec::new();

    unsafe { vec.set_len(100); }      // <- unsafe

    let val = vec.get(5).unwrap();     // <- UB
    println!("{}", val);

그것은 나에게 unsafe에 대한 오해처럼 보입니다. unsafe는 "여기 내부에서 안전하지 않은 작업이 발생합니다"라고 표시하지 않습니다. 그것은 "여기에서 필요한 불변성을 지지한다는 것을 보증합니다."라고 표시합니다. 대기 지점에서 불변을 유지할 수는 있지만 가변 매개변수가 포함되지 않기 때문에 불변을 유지하는지 확인하는 매우 명확한 사이트가 아닙니다. 호출 사이트에서 불변성을 유지하도록 보장하기 위해 훨씬 더 합리적이고 모든 안전하지 않은 추상화가 작동하는 방식과 훨씬 더 일관성이 있습니다.

이것은 안전하지 않은 효과를 생각하는 것이 부정확한 직관으로 이어지는 이유와 관련이 있습니다. 불안전성은 구체적으로 의도적으로 전염되는 것이 아닙니다 . 다른 안전하지 않은 함수를 호출하는 안전하지 않은 함수를 작성하고 해당 불변량을 호출 스택으로 전달할 수 있지만 이것은 안전하지 않은 것이 전혀 사용되는 일반적인 방법이 아니며 실제로 값에 대한 계약을 정의하고 수동으로 확인하는 데 사용되는 구문 마커입니다. 당신은 그들을 지지합니다.

따라서 모든 디자인 결정에 전체 RFC가 필요한 것은 아니지만 결정이 내려지는 방식에 대해 보다 명확하고 구조를 제공하기 위해 노력하고 있습니다. 이번 호 서두의 주요 결정 사항 목록이 그 예입니다. 우리가 사용할 수 있는 도구를 사용하여 안전하지 않은 비동기 fns 문제에 대한 구조화된 합의 지점을 살펴보고 싶습니다. 그래서 이것은 설문조사가 포함된 요약 게시물입니다.

async unsafe fn

async unsafe fns는 unsafe 블록 내에서만 호출할 수 있는 비동기 함수입니다. 그들의 신체 내부는 안전하지 않은 범위로 취급됩니다. 주요 대안 설계는 async unsafe fns 를 호출하는 대신 await 에 대해 안전하지 않게 만드는 것입니다. 호출하기에 안전하지 않은 디자인을 선호하는 여러 가지 확실한 이유가 있습니다.

1. 호출하기에 안전하지 않은 non-async unsafe fns의 동작과 구문적으로 일치합니다.
2. 일반적으로 unsafe가 작동하는 방식과 더 일치합니다. 안전하지 않은 함수는 호출자가 유지하는 일부 불변에 의존하는 추상화입니다. 즉, "안전하지 않은 작업이 발생하는 곳"을 표시하는 것이 아니라 "불변성이 유지되는 것이 보장되는 곳"을 표시하는 경우입니다. 인수가 선택되고 검증된 시점과 별도로 대기 사이트에서보다 인수가 실제로 지정된 호출 사이트에서 불변량이 유지되는지 확인하는 것이 훨씬 더 합리적입니다. 이것은 일반적으로 안전하지 않은 기능에 대해 매우 정상이며, 다른 안전한 기능이 정확할 것으로 기대하는 일부 상태를 결정하는 경우가 많습니다.
3. 이는 async 수정자를 제거하고 향후 반환 유형을 래핑하는 것과 동일하게 서명을 모델링할 수 있는 async fn 서명의 디슈가링 개념과 더 일치합니다.
4. 대안은 단기 또는 중기(몇 년을 의미)에 구현하기에는 실행 가능하지 않습니다. 현재 설계된 Rust 언어로 폴링하기에 안전하지 않은 미래를 만들 방법은 없습니다. 일종의 "효과로서의 안전하지 않은"은 광범위한 영향을 미치며 오늘날 이미 존재하는 안전하지 않은 기능(예: 정상적인 안전하지 않은 기능 및 블록)과 역호환되는 방식을 처리해야 하는 거대한 변경이 될 것입니다. async unsafe fns를 추가해도 해당 환경이 크게 변경되지 않는 반면, 현재 unsafe에 대한 해석에 따른 async unsafe fns는 단기 및 중기적으로 실제 사용 사례가 있습니다.

@rfcbot ask lang "안정화 async unsafe fn을 호출하기에 안전하지 않은 async fn으로 허용합니까?"

rfcbot으로 설문조사를 하는 방법을 모르지만 적어도 지명했습니다.

@withoutboats 팀 구성원이 T-lang에 다음 사항에 대한 합의를 요청했습니다.

"불안정한 비동기 fn 안정화를 호출하기에 안전하지 않은 비동기 fn으로 허용합니까?"

• [x] @센트릴
• [x] @cramertj
• [x] @eddyb
• [ ] @joshtriplett
• [x] @nikomatsakis
• [ ] @pnkfelix
• [ ] @scottmcm
• [x] @withoutboats

@withoutboats

이 안전하지 않은 비동기 fns 문제에 대해 구조화된 합의점을 확인하고 싶습니다. 그래서 이것은 설문조사가 포함된 요약 게시물입니다.

작성해주셔서 감사합니다. 토론을 통해 오늘 밤에 작동하는 async unsafe fn 가 올바르게 작동한다고 확신했습니다. (일부 테스트는 희소하게 보였기 때문에 추가되어야 할 것입니다.) 또한, 보고서의 일부와 async unsafe fn 작동 방식에 대한 설명으로 상단의 보고서를 수정해 주시겠습니까?

일반적으로 unsafe가 작동하는 방식과 더 일치합니다. 안전하지 않은 함수는 호출자가 유지하는 일부 불변에 의존하는 추상화입니다. 즉, "안전하지 않은 작업이 발생하는 곳"을 표시하는 것이 아니라 "불변성이 유지되는 것이 보장되는 곳"을 표시하는 경우입니다. 인수가 선택되고 검증된 시점과 별도로 대기 사이트에서보다 인수가 실제로 지정된 호출 사이트에서 불변량이 유지되는지 확인하는 것이 훨씬 더 합리적입니다. 이것은 일반적으로 안전하지 않은 기능에 대해 매우 정상이며, 다른 안전한 기능이 정확할 것으로 기대하는 일부 상태를 결정하는 경우가 많습니다.

너무 세심한주의를 기울이지 않는 사람으로서 여기에 동의하고 해결책이 좋은 문서라고 생각합니다.

나는 여기에서 벗어난 것일 수도 있지만, 그 점을 감안할 때

• 선물은 본질적으로 조합적이며 구성 가능한 것이 기본입니다.
• 미래 구현 내부의 대기 지점은 일반적으로 보이지 않는 구현 세부 사항입니다.
• 미래는 실행 컨텍스트에서 매우 멀리 떨어져 있으며 실제 사용자는 루트가 아닌 중간에 있을 수 있습니다.

특정 사용/행동에 따라 달라지는 불변성은 나쁜 생각과 안전한 규칙이 불가능한 것 사이 어딘가에 있는 것 같습니다.

대기된 출력 값이 불변성을 유지하는 것과 관련된 경우가 있는 경우 미래에는 다음과 같이 안전하지 않은 액세스가 필요한 래퍼인 출력이 있을 수 있다고 가정합니다.

struct UnsafeOutput<T>(T);
impl<T> UnsafeOutput<T> {
    unsafe fn unwrap(self) -> T { self.0 }
}

unsafe ness가 이 "early unsafe"에서 async ness 앞에 있다는 점을 감안할 때 수정자 순서가 unsafe async fn 보다 async unsafe fn unsafe async fn 것이 훨씬 더 행복할 것입니다 async unsafe fn , unsafe (async fn) 가 async (unsafe fn) 보다 훨씬 더 명확하게 해당 동작에 매핑되기 때문입니다.

둘 다 기꺼이 받아들이겠지만, 여기에 노출된 래핑 순서에는 외부에 unsafe 가 있고 수정자의 순서는 이것을 명확히 하는 데 도움이 될 수 있습니다. ( unsafe 는 async fn 대한 수정자이며 async 대한 수정자는 unsafe fn 아닙니다.)

둘 다 기꺼이 받아들이겠지만, 여기에 노출된 래핑 순서에는 외부에 unsafe 가 있고 수정자의 순서는 이것을 명확하게 하는 데 도움이 될 수 있습니다. ( unsafe 는 async fn 대한 수정자이며 async 대한 수정자는 unsafe fn 아닙니다.)

나는 당신의 마지막 괄호 부분까지 당신과 함께했습니다. @withoutboats ' 작성을 보면 호출 사이트에서 안전하지 않은 문제가 처리되는 경우 실제로 가지고 있는 것은 unsafe fn (비동기 컨텍스트에서 호출됨)라는 것을 매우 분명하게 보여줍니다.

나는 우리가 자전거 보관소 async unsafe fn 페인트한다고 말하고 싶습니다.

async unsafe fn 가 더 합리적이라고 생각하지만 async, unsafe, const 중 어떤 순서도 문법적으로 받아들여야 한다고 생각합니다. 그러나 async unsafe fn 는 비동기를 제거하고 반환 유형을 수정하여 "디슈가(desugar)"한다는 개념으로 나에게 더 의미가 있습니다.

대안은 단기 또는 중기(몇 년을 의미)에 구현하기에는 실행 가능하지 않습니다. 현재 설계된 Rust 언어로 폴링하기에 안전하지 않은 미래를 만들 방법은 없습니다.

FWIW unsafe fn 내부의 클로저와 함수 특성과 관련하여 RFC2585 에서 언급한 유사한 문제에 부딪쳤습니다. unsafe async fn 가 안전한 poll 메서드로 Future unsafe async fn 를 반환할 것이라고 기대하지 않았지만 대신 unsafe 로 UnsafeFuture 를 반환합니다. 투표 방식. (*) unsafe { } 블록 내에서 사용될 때 .await 도 UnsafeFuture 에서 작동하도록 만들 수 있지만 그렇지 않으면 작동하지 않습니다.

이 두 가지 미래 특성은 오늘날 우리가 가진 것과 관련하여 큰 변화가 될 것이며 아마도 많은 구성 가능성 문제를 일으킬 것입니다. 그래서 대안을 탐색하는 배는 아마도 항해했을 것입니다. 특히 이것은 Fn 트레잇 이 오늘날 작동하는 방식과 다르기 때문에(예: UnsafeFn 트레잇 또는 이와 유사한 것이 unsafe fn 내부에 클로저를 생성하는 것이었습니다 impls Fn() 즉, 이 클로저가 안전하지 않은 함수를 호출할 수 있지만 호출하기에 안전한 클로저를 반환합니다.

"안전하지 않은" Future 또는 클로저를 생성하는 것은 문제가 아닙니다. 문제는 그렇게 하는 것이 안전하다는 것을 증명하지 않고 호출하는 것입니다. 특히 유형이 이것이 수행되어야 한다고 말하지 않는 경우에는 더욱 그렇습니다.

(*) 모든 Future UnsafeFuture 대해 UnsafeFuture 자체를 "풀기"하는 unsafe 메서드도 제공할 수 있습니다. A와 Future 에 안전 poll .

여기 내 두 센트가 있습니다.

• @cramertj 의 설명(https://github.com/rust-lang/rust/issues/62149#issuecomment-510166207)을 보면 unsafe 비동기 함수가 올바른 디자인이라고 확신합니다.
• 나는 unsafe 및 async 키워드의 고정된 순서를 매우 선호합니다.
• 나는 순서가 더 논리적으로 보이기 때문에 unsafe async fn 순서를 약간 선호합니다. "빠른 전기 자동차" 대 "전기 빠른 자동차"와 유사합니다. 주로 async fn 디슈가를 fn 입니다. 따라서 두 개의 키워드가 서로 옆에 있다는 것은 의미가 있습니다.

let f = unsafe { || { ... } } 는 f 안전하게 만들고 UnsafeFn 특성을 도입해서는 안 되며 선험적으로 .await ing 및 async unsafe fn 는 안전한. 모든 UnsafeFuture 강력한 근거가 필요합니다!

이 모든 것은 unsafe 가 명시적이어야 하고 Rust가 당신을 안전한 땅으로 다시 밀어 넣어야 하기 때문에 따릅니다. 또한 이 토큰으로 f 의 ... 는 안전하지 않은 블록이 _not_ 되어야 하고, https://github.com/rust-lang/rfcs/pull/2585 가 채택되어야 하며, async unsafe fn 은 몸이 안전해야 합니다.

나는 이 마지막 점이 오히려 결정적일 수 있다고 생각합니다. 모든 async unsafe fn 가 unsafe 블록을 사용하는 것이 가능하지만, 유사하게 대부분은 약간의 안전 분석을 통해 이점을 얻을 수 있으며 많은 사람들이 쉽게 실수할 만큼 복잡하게 들립니다.

특히 클로저를 캡처할 때 차용 검사기를 우회해서는 안 됩니다.

그래서 여기 내 의견: https://github.com/rust-lang/rust/issues/62149#issuecomment -511116357은 매우 나쁜 생각입니다.

UnsafeFuture 트레잇은 호출자가 미래를 폴링하기 위해 unsafe { } 를 작성하도록 요구하지만 호출자는 어떤 의무가 거기에서 입증되어야 하는지 알지 못합니다. 예를 들어 Box<dyn UnsafeFuture> 는 unsafe { future.poll() } 안전합니까? 모든 선물을 위해? 당신은 알 수 없습니다. 따라서 @rpjohnst 가 유사한 UnsafeFn 특성에 대한 불일치에 대해 지적했듯이 이것은 완전히 쓸모가 없습니다.

Future's가 폴에 항상 안전하도록 요구하는 것은 의미가 있으며 폴에 안전해야 하는 미래를 구성하는 프로세스는 안전하지 않을 수 있습니다. 나는 그것이 async unsafe fn 라고 생각한다. 그러나 이 경우 fn 항목은 반환된 미래가 폴링하기에 안전하도록 유지되어야 하는 항목을 문서화할 수 있습니다.

@rfcbot 구현-작업-차단-안정화

내가 아는 한 (https://github.com/rust-lang/rust/issues/61949, https://github.com/rust-lang/rust/issues/62517) 2개의 알려진 구현 차단기가 있습니다. 몇 가지 테스트를 추가하는 것이 좋습니다. 저는 rfcbot이 시간적으로 우리의 차단기가 되지 않도록 하는 문제를 해결하고 있으며 대신 수정 사항을 실제로 차단할 것입니다.

@rfcbot은 구현-작업-차단-안정화를 해결합니다.

:bell: 위 의 이제 최종 댓글 기간에 접어들었습니다 . :벨:

https://github.com/rust-lang/rust/pull/63209 에 안정화 PR을 제출했습니다

위 의 병합 처리가 포함된 최종 의견 수렴 기간이 이제 완료되었습니다 .

거버넌스 프로세스의 자동화된 대표자로서 나는 그들의 작업에 대해 저자와 기여한 다른 모든 사람들에게 감사하고 싶습니다.

RFC는 곧 병합됩니다.

여기서 안정화하고 있는 흥미로운 측면은 안전한 코드에서 사용할 수 있는 자체 참조 구조체를 만들고 있다는 것입니다. 이것을 흥미롭게 만드는 것은 Pin<&mut SelfReferentialGenerator>에서 전체 생성기 상태를 가리키는 변경 가능한 참조(Pin에 필드로 저장됨)가 있고 해당 상태 내부에 상태의 다른 부분을 가리키는 포인터가 있다는 것입니다. . 내부 포인터는 변경 가능한 참조로 별칭을 지정합니다!

이에 대한 후속 조치로 @comex는 실제로 우리가 현재 내보내는 방식으로 LLVM의 noalias 주석을 위반하는 (안전한) 비동기 Rust 코드를 작성 했습니다. 하지만 TLS 사용으로 인해 현재 잘못된 컴파일은 없는 것으로 보입니다.