On my first implementation, i tried to run the dispatcher in its dedicated
thread. But it was quite dumb because all code ended up running inside this
thread.
For me the problematics are :
* Is it really necessary ? Having a 1:N model doesn't prevent multithreading.
But distribution of work will rely on the shoulder's of the user.
* For what usage ? I'm rather against an invasive N:M model like Go, I prefer
to let the user have full control. My goal with NimGo is flexibility and ease
of use, not performance. I think performance could be better achieve by other
solutions (threads+asyncdispatch or threads+event dispatcher). I must admit I
now nothing about socket programming, so maybe there is a real need for this,
but I'm not competent.
* I also think that CPS would be a better candidate, I heard it plays much
more nicely with threads.
* It would mean abandoning closures, which is IMHO one of the best selling
point of Go (and NimGo). Closures memory cannot be tricked as easy than ref
memory. Return values are also more complicated. Maybe something could be
achieve by extensive use of macro...
Look at that beauty of closures. Just so simple and evident for grok
programmers:
var data = "blah"
echo "bytes count=", goAndWait proc(): int =
[... do other async stuff...]
return goStdout.write(data)
Run
* Not sure how it might impact exception handling
* There is also the problematic of job stealing with other threads
* It would also mean adding a lot of boilerplate (SharedPtr, locks and so)
* Is it worth your time 🙃 ?
* Would I have time (and willingness for this) ? I worked at night on this
(and sadly developping is not what I do for living) and wants to advance on my
other nim's project which are really important to me !
* There are also more obstacles I haven't though of I am sure
