Ah ah. I must admit I have just too much pleasure to work on my NimGo project.
Not to hard but still challenging and very educational.
std/tasks is very smart and good. But when I saw the compile time I freaked out
a little. It cannot be used with NimGo where thousands to millions of procs
must be "taskified" (maybe not such a relevant problem with IC, after all we
rarely create a thousands tasks in the same file).
Even if that would be a pleasure to collaborate with other people on a project
like NimGo. I don't really see where what M:N will ends up. It might just make
it a worse library.
> Just let me annotate the inherent parallelism/concurrency in my program and
> then the runtime can figure out if I'm IO bound or CPU bound
Why not instead do this :
proc cpuTask() = discard
proc IOTask() = discard
proc mixTask() =
waitAll(
goAsync IoTask(),
goThread CpuTask()
)
goAndWait mixTask()
Run
Simple, elegant, no complex macro. `goTask` would just be a wrapper around
createThread + GoChannel.
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.
> Just let me compose libraries. Let me make a webservice out of my image
> processing application.
Idem, a "GoChannel" (sorry to name everything Go, that's shorter) would
certainly be enough while maintaining high throughput.
Of course, that relies the burden of the programmer, who would have to
understand the difference and knows what is code do (might not be an
straightforward). I also see one main advantage to using GoChannel : we would
have two distinct library working together. A threadpool library and NimGo. The
threadpool won't need to know NimGo's API, and NimGo won't have to bother with
thread concerns. Only GoChannel will link them and make them work together.
There certainly already exists a good threadpool library to use without
reinventing the wheel. Of course it would use spawn/wait/FlowVar[T] API, with
its goods and bads (sorry malebolgia !)
The real use case IMHO would be to make NimGo handles millions of I/O at the
same time, without the help of threads, it is just not possible, the I/O loop
is not free. But I think that "particular" case would be better handle by
another library than NimGo.
