Go Generator의 채널 폐쇄에 대한 책임은 어떻게 처리되어야 합니까?

Yield를 사용한 생성기의 관용적 구현

Go에서 Yield를 사용하여 생성기를 구현하는 것은 일반적으로 고루틴과 채널의 조합을 통해 달성됩니다. 생성기 함수는 채널을 통해 값을 생성하는 고루틴을 생성하고 소비자 함수는 for-range 루프의 채널에서 해당 값을 받습니다.

채널 폐쇄에 대한 책임

에 따르면 Go 관용구로, 채널을 닫는 책임은 생성기 기능에 있습니다. 생성기는 반복이 언제 완료되는지 알고 있으므로 더 이상 값이 수신되지 않을 것임을 소비자에게 알리기 위해 채널을 닫아야 합니다.

Caller Deferring Close()를 사용하여 수정된 코드

수정된 코드에서는 생성기 함수에서 채널을 닫지 않음으로써 호출자에게 채널을 닫는 책임을 올바르게 부여했습니다. 하지만 이미 닫힌 채널을 닫는 것은 올바르지 않으므로 main() 함수에서 close() 호출도 제거해야 합니다.

package main

import (
    "./lib"
    "fmt"
)

var (
    fruits  = []string{"apple", "banana", "cherry", "durian"}
    banned = "durian"
)

func main() {
    channel := lib.PermutateWithChannel(fruits)
    defer close(channel) // Defer closing the channel

    for myFruits := range channel {
        fmt.Println(myFruits)
        if myFruits[0] == banned {
            break // Break from the loop instead of closing the channel
        }
    }
}

닫힌 채널 닫기의 부정적인 부작용

호출자가 채널을 닫을 때 이후에 채널에 값을 보내려고 하면 런타임 패닉이 발생합니다. 채널이 폐쇄된 것으로 표시되어 있고, 폐쇄된 채널로 보내는 것은 불법이기 때문입니다. 그러나 이 패닉은 값 전송을 시도한 고루틴을 종료하는 것 이상의 부정적인 부작용이 없습니다.

수신 전용 채널 반환 유형

라이브러리 함수에서 반환된 채널을 수신하도록 제한하려면 -전용, 호출자가 채널을 닫을 수 있도록 허용하면서 채널을 래핑하고 수신 전용만 노출하는 새로운 유형을 도입할 수 있습니다. 채널:

type ReceiveOnlyChannel <-chan []string

func NewReceiveOnlyChannel(channel <-chan []string) *ReceiveOnlyChannel {
    return (*ReceiveOnlyChannel)(&channel)
}

func PermutateWithChannel(strings []string) *ReceiveOnlyChannel {
    // ... (same as before, except it returns ReceiveOnlyChannel)
}

채널을 새로운 유형으로 래핑하면 호출자가 래퍼 유형의 Close() 메서드를 통해 채널을 닫을 수 있도록 허용하면서 작업 수신에만 액세스하도록 제한할 수 있습니다.

위 내용은 Go Generator의 채널 폐쇄에 대한 책임은 어떻게 처리되어야 합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!