Is anything along the lines of Goroutines possible (or even planned) for Nim?
That is, something along the lines of Go, where potentially tens of thousands of lightweight "threads" can be launched, but actually run on a much smaller pool of operating system threads.
This would be useful for things like large-scale web services, massive real-time chat rooms, massively multiplayer game servers, maybe for entity/component game systems, and probably many other things.
So something like an HTTP or WebSockets server would need to implement it's own thread-pool, or share one as a library.
Yeah, I don't see that as a big miss for version 1 - having something like this at the language-level is "nice to have", but that kind of scale is only really necessary in a few extreme cases, and a userland library could probably implement this is a reuseable and quite elegant manner with Nim :-)
You can't move a routine from one thread to another but I'm not sure that feature is particularly useful or important
Agree - does Go do that? I wonder why.
You can't move a routine from one thread to another but I'm not sure that feature is particularly useful or important
does Go do that? I wonder why.
The go scheduler is preemptive, also when a goroutine blocks on a syscall it can just schedule another.
so Erlang remain the king here ;-)
according the doc:
hope that in far future Nim become a competitor here
@dom96: > Don't Goroutines also use async IO in the background?
I believe you are right. That's the appeal - you write IO code in synchronous style (i.e no callbacks or promises). Underneath as soon as the goroutine is waiting on IO, the thread will suspend it and schedule a different runnable routine. IO is only one of many places where a goroutine switch can happen.
but I imagine that GC should stop at some points so question: is it possible to use that as a place to check for switching (using a counter)
To get it right it'd require more than just adding a preemption hook. Keep in mind that the goroutine runtime (scheduler, stack manager, etc...) has evolved over time, i.e. it has had its growing pains.
@vbtt
The point is that once assigned, a running routine cannot be moved to a different thread - that's a runtime feature/restriction. So if one routine hogs the CPU, the other routines on that thread will starve, even if other CPUs are idle.
Understood, but if you really need thousands (or tens of thousands of routines) running at the same time, isn't it likely those are all going to be relatively short-lived routines?
In the case of something like a web-application, I would under any circumstances always use a background worker queue of some sort, for anything that's going to run for longer periods of time - so, for example, a web app might use short-lived routines for controllers/actions, rendering views, making short round-trips to the database, etc.; while something that takes longer, like sending an e-mail, would go into a worker queue which will run under a separate process in the background on a much lower number of OS threads, e.g. up to 8 threads on an 8-core system.
@Araq:
Interesting, that's good to know. Anyway, I don't think closure iterator migration is a worthwhile cause at this point.
@mindplay:
Firstly, I'm not particularly keen on being able to move running routines, but I just want to point out the (stated) benefits. It's not just with a large number of routines, or long running ones. Even in a simple web-app where you have, say, 50-100 routines running, you can have one that goes into a tight loop for a while (has to be CPU loop, IO wait doesn't matter because the routine is suspended anyway and the thread is available) - this will starve the other routines in the same thread, until the routine continues and does some IO. This type of stuff basically effects variance of the response time. You will have spikes in response time - some requests will take much longer than others. Keeping variance low also requires preemptive scheduling, so we're taking about stuff not there in Nim anyway.
vbtt: Firstly, I'm not particularly keen on being able to move running routines, but I just want to point out the (stated) benefits.
I think we all (or at least most of us) know the benefits. The problem is that the benefits aren't free; for example, Go sacrifices a fair amount of memory safety to accomplish its goals and its scheduler can have issues dealing with foreign language libraries that are unaware of it. There are ways to reify a process algebra in a programming language (which is was Go does) that does not have this defect (but of course has different types of tradeoffs).
I create a tiny project to implement goroutine like light-weight thread, similar to spawn but with some additional functions(light-weight thread channel...).
Project host here: https://github.com/rogercloud/nim-routine
The project is still in develop, any PRs, adivce or bug report is welcome.