> the GoChannel will be a channel that detects when we are on a coroutine and > will suspend only the coroutine and not the thread. The dispatcher would have > the additional job to queue read available channels and resume the correspond > coroutines. I think a channel with 1 blocking receiver: N non blocking sender > won't be so difficult to implement and corresponds to most needs.
Well that pattern works really well with async + thread pools which are also 1:N in Nim. As you say, you can use any threadpool to distribute the work and just use the "GoChannels" to notify the goroutine event loop that work has finished. I always think of them as queues rather than channels, but they have almost the same API. I've actually built an image processing prototype like this with opencv in Nim with std/async and threading/channels. Wrangling the C++ opencv matrix type was the most painful part. Though of course an M:N model would be awesome and fun. Personally, I wanna fixup ORC's cycle collector to be thread-safe capable. :)
