Prioridad en Go, seleccione la solución de la solución

Question

Deseo tener una rutina de escucha en dos canales, bloqueada cuando se agotan ambos canales. Sin embargo, si ambos canales contienen datos, quiero que uno sea drenado antes de que se maneje el otro.

En el siguiente ejemplo de trabajo, deseo que todos los out se vacíen antes de manipular exit. Utilizo una declaración select-que no tiene ningún orden de prioridad. ¿Cómo puedo solucionar el problema, haciendo que los 10 valores positivos se manejen antes de la salida?

package main 

import "fmt" 

func sender(out chan int, exit chan bool){ 
    for i := 1; i <= 10; i++ { 
     out <- i 
    } 
    exit <- true 
} 

func main(){ 
    out := make(chan int, 10) 
    exit := make(chan bool) 

    go sender(out, exit) 

    L: 
    for { 
     select { 
      case i := <-out: 
       fmt.Printf("Value: %d\n", i) 
      case <-exit: 
       fmt.Println("Exiting") 
       break L 
     } 
    } 
    fmt.Println("Did we get all 10? Most likely not") 
} 

Answer 1

package main 

import "fmt" 

func sender(out chan int, exit chan bool) { 
    for i := 1; i <= 10; i++ { 
     out <- i 
    } 
    exit <- true 
} 

func main() { 
    out := make(chan int, 10) 
    exit := make(chan bool) 

    go sender(out, exit) 

    for { 
     select { 
     case i := <-out: 
      fmt.Printf("Value: %d\n", i) 
      continue 
     default: 
     } 
     select { 
     case i := <-out: 
      fmt.Printf("Value: %d\n", i) 
      continue 
     case <-exit: 
      fmt.Println("Exiting") 
     } 
     break 
    } 
    fmt.Println("Did we get all 10? I think so!") 
} 

El caso predeterminado de la primera selección lo hace no bloqueante. La selección drenará el canal de salida sin mirar el canal de salida, pero de lo contrario no esperará. Si el canal de salida está vacío, inmediatamente cae a la segunda selección. La segunda selección es bloqueo. Esperará datos en cualquier canal. Si llega una salida, la maneja y permite que el bucle salga. Si se reciben datos, vuelve a la parte superior del ciclo y regresa al modo de drenaje.

Answer 2

Otro enfoque:

package main 

import "fmt" 

func sender(c chan int) chan int { 
     go func() { 
       for i := 1; i <= 15; i++ { 
         c <- i 
       } 
       close(c) 
     }() 
     return c 
} 

func main() { 
     for i := range sender(make(chan int, 10)) { 
       fmt.Printf("Value: %d\n", i) 
     } 
     fmt.Println("Did we get all 15? Surely yes") 
} 

---

$ go run main.go 
Value: 1 
Value: 2 
Value: 3 
Value: 4 
Value: 5 
Value: 6 
Value: 7 
Value: 8 
Value: 9 
Value: 10 
Value: 11 
Value: 12 
Value: 13 
Value: 14 
Value: 15 
Did we get all 15? Surely yes 
$ 

Answer 3

He creado una solución bastante simple. Se hace lo que quiero, pero si alguien tiene una mejor solución, por favor hágamelo saber:

exiting := false 
for !exiting || len(out)>0 { 
    select { 
     case i := <-out: 
      fmt.Printf("Value: %d\n", i) 
     case <-exit: 
      exiting = true 
      fmt.Println("Exiting") 
    } 
} 

en lugar de salir a la recepción, me BANDERA una salida, la salida una vez que me he asegurado de que no queda nada en chan out .

Answer 4

el idioma es compatible de forma nativa y no se requiere ninguna solución. Es muy simple: el canal de salida solo debe ser visible para el productor. Al salir, el productor cierra el canal. Solo cuando el canal está vacío y cerrado, el consumidor se da por vencido. Esto se hace posible mediante la lectura de la canal como sigue:

v, ok := <-c 

Esto establecerá ok a un valor booleano que indica si o no el valor v se leyó realmente fuera de la canal (ok == true), o si v se fijó a la valor cero del tipo manejado por el canal c porque c está cerrado y vacío (ok == false). Cuando el canal está cerrado y no está vacío, v tendrá un valor válido y ok será true. Cuando el canal está cerrado y vacío, v será el valor cero del tipo manejado por el canal c, y ok será false, lo que indica que v es inútil.

Aquí se muestra un ejemplo para ilustrar:

package main 

import (
    "fmt" 
    "math/rand" 
    "time" 
) 

var (
    produced = 0 
    processed = 0 
) 

func produceEndlessly(out chan int, quit chan bool) { 
    defer close(out) 
    for { 
     select { 
     case <-quit: 
      fmt.Println("RECV QUIT") 
      return 
     default: 
      out <- rand.Int() 
      time.Sleep(time.Duration(rand.Int63n(5e6))) 
      produced++ 
     } 
    } 
} 

func quitRandomly(quit chan bool) { 
    d := time.Duration(rand.Int63n(5e9)) 
    fmt.Println("SLEEP", d) 
    time.Sleep(d) 
    fmt.Println("SEND QUIT") 
    quit <- true 
} 

func main() { 
    vals, quit := make(chan int, 10), make(chan bool) 
    go produceEndlessly(vals, quit) 
    go quitRandomly(quit) 
    for { 
     x, ok := <-vals 
     if !ok { 
      break 
     } 
     fmt.Println(x) 
     processed++ 
     time.Sleep(time.Duration(rand.Int63n(5e8))) 
    } 
    fmt.Println("Produced:", produced) 
    fmt.Println("Processed:", processed) 
} 

esto está documentado en la sección "Recibir del operador" de la especificación ir: http://golang.org/ref/spec#Receive_operator

Answer 5

En mi caso, tenía muchas ganas de dar prioridad a los datos de una canal sobre otro, y no solo tiene una señal de salida fuera de banda.Para el beneficio de cualquier otra persona con el mismo problema Creo que este enfoque funciona sin la condición de carrera potencial:

OUTER: 
for channelA != nil || channelB != nil { 

    select { 

    case typeA, ok := <-channelA: 
     if !ok { 
      channelA = nil 
      continue OUTER 
     } 
     doSomething(typeA) 

    case nodeIn, ok := <-channelB: 
     if !ok { 
      channelB = nil 
      continue OUTER 
     } 

     // Looped non-blocking nested select here checks that channelA 
     // really is drained before we deal with the data from channelB 
     NESTED: 
     for { 
      select { 
      case typeA, ok := <-channelA: 
       if !ok { 
        channelA = nil 
        continue NESTED 
       } 
       doSomething(typeA) 

      default: 
       // We are free to process the typeB data now 
       doSomethingElse(typeB) 
       break NESTED 
      } 
     } 
    } 

} 

Answer 6

creo que la respuesta de Sonia es incorrect.This es mi solución, un poco complicar bits.

package main 

import "fmt" 

func sender(out chan int, exit chan bool){ 
    for i := 1; i <= 10; i++ { 
     out <- i 
    } 
    exit <- true 
} 

func main(){ 
    out := make(chan int, 10) 
    exit := make(chan bool) 

    go sender(out, exit) 

    L: 
    for { 
     select { 
      case i := <-out: 
       fmt.Printf("Value: %d\n", i) 
      case <-exit: 
       for{ 
        select{ 
        case i:=<-out: 
         fmt.Printf("Value: %d\n", i) 
        default: 
         fmt.Println("Exiting") 
         break L 
        } 
       } 
       fmt.Println("Exiting") 
       break L 
     } 
    } 
    fmt.Println("Did we get all 10? Yes!") 
} 

Answer 7

¿Hay alguna razón específica para el uso de un canal tamponada make(chan int, 10)?

Necesita usar un canal sin buffer vs buffer, que está utilizando.

Simplemente elimine 10, debería ser solo make(chan int).

esta forma de ejecución de la función sender sólo puede proceder a la declaración exit <- true después del último mensaje del canal de out se quita de la cola por la declaración i := <-out. Si esa declaración no se ha ejecutado, no hay forma de que se pueda alcanzar el exit <- true en la rutina.

Answer 8

Aquí hay otra opción. Código

Consumidor:

go func() { 
    stop := false 
    for { 
     select { 
     case item, _ := <-r.queue: 
     doWork(item) 
     case <-r.stopping: 
     stop = true 
     } 
     if stop && len(r.queue) == 0 { 
     break 
     } 
    } 
    }()