Mirror of forum.nim-lang.org

1558 :: Closed channels

• mora (orginal) [2015-08-18T12:38:37+02:00] view original

  Hi,

  Two questions about channels. I believe that we should do first (or something similar). The second question is whether we want to have something like in Go. There are plenty of examples and patterns about these, if you need motivation, then I'll write here some.

  Q1. Currently if we close() a channel and there are still unread messages, then we can't read them. I think that this should be changed, because we could close() a channel to indicate that there won't be any more messages. Let's have three states:

  • alive and open
  • alive and closed: somebody called close(), but there are still unread messages
  • dead and closed: somebody called close() and there are no unread messages, the resources have been freed

  Then we could have functions for test these (isAlive(), isDead(), isClosed(), isOpen). What do you think? If you like this, then I'll implement and send PR.

  Q2. When we open() a channel then we could have an extra parameter for how many messages can be stored. Namely, if we open it with chan.open(3), and we try to send a message for the fourth time without reading so far, then it would block the fourth send(...) command until somebody reads from the channel. This should be optional, the default behavior would be no limit.

  Thank you,

  Peter

---

• Araq (orginal) [2015-08-18T14:55:09+02:00] view original

  Q1: Sounds very good to me, please make it happen. Q2: Dunno, I don't like blocking too much, it's too prone to deadlocking a critical producer.

---

• mora (orginal) [2015-08-23T22:08:58+02:00] view original

  I'm working on Q1. However, I found two problems so far.

  • I need to change the current API. The recv(c): TMsg function is waiting until there is a new message. If we close the channel instead of sending a new message, then there is no point in blocking recv, so we should return it, but with what? I guess that there should be recv(c): (TMsg, bool) (like in Go), or I prefer recv(c, msg: var TMsg): bool so you could read the channel like this:

  var T msg
  while c.recv(msg):
    print "received: ", msg
  Run

  • I can't see when I can close a mutex properly. Namely, if you close a channel, then I can free up all the resources except the mutex. I thought about many solutions, but all have race condition issue. If I free up the mutex and have a variable to indicate that the channel is closed and dead (like currently mask == ChannelClosedMask), then any recv function should check this variable first, and then touch the mutex. However, this is not correct: if a recv function checks this mask parameter first, then we cannot be sure that the mutex is still open one line later.

  Regarding to Q2, I used and liked a pattern in Go, where a limit on the channel was useful. I started threads and each thread sent one message to the same channel, did some heavy work, then read one message just before exiting. The length of the buffer was set to the number of processors. I'll put it into a separate PR, so we can discuss separately.

---

• Araq (orginal) [2015-08-23T22:55:39+02:00] view original

  I started threads and each thread sent one message to the same channel, did some heavy work, then read one message just before exiting. The length of the buffer was set to the number of processors.

  That reads like a hacky way to do a barrier.

---