Mirror of forum.nim-lang.org

6615 :: is chan.tryRecv() not supposed to wait for the next item te be sent via the channel?

• Serge (orginal) [2020-07-29T16:27:49+02:00] view original

  In the code hereunder, if do not put a long enough delay in the loop which calls chan.tryRecv(), the main thread will fail to read from chan and exit, is that the expected behavior of threadpools in Nim?

   os
  import threadpool
  import strformat
  
  var chan: Channel[string]
  open(chan)
  
  
  proc sayHello() =
      for i  in 0..10:
          chan.send(fmt"Hello {i} !")
          sleep(5)
  
  proc sayBye() =
      for i in 0..10:
          chan.send(fmt"Bye {i} !")
          sleep(10)
  
  spawn sayHello()
  spawn sayBye()
  
  
  while true:
    let tried = chan.tryRecv()
    if tried.dataAvailable:
      echo tried.msg
      sleep(100)
    else:
      break
  Run

---

• Araq (orginal) [2020-07-29T16:59:37+02:00] view original

  You are looking for ordinary recv.

---

• Serge (orginal) [2020-07-29T17:14:52+02:00] view original

  Thank you!

---

• Serge (orginal) [2020-07-31T13:13:53+02:00] view original

  Does Nim implement something similar to the channel / select pattern in Go ?

  It is useful for dealing with a plurality of incoming messages on many channels concurrently.

  
      select {
      case msg := <-messages:
          fmt.Println("received message", msg)
      case sig := <-signals:
          fmt.Println("received signal", sig)
      default:
          fmt.Println("no activity")
      }
  Run

---

• jibal (orginal) [2020-08-01T06:10:39+02:00] view original

  tryFoo, in Nim and elsewhere, usually means don't hang, produce an exception, etc. if something fails, so without reading the documentation I would expect tryRecv not to wait and for there to be a corresponding recv that does wait. Of course, reading the documentation one sees that's the case. (Although I think the recv doc should refer to tryRecv rather than peek, and the tryRecv doc should refer to recv.)

---