> Native thread implementations everywhere incur several hundred kilobytes,
> minimum, per stack, usually much more.
The in-kernel native thread implementation only takes about 4 kilobytes per thread. It is pthreads that determines your userspace thread stack size.
In the past, Linux didn't really support massive numbers of native threads very well. That has improved over the years with NPTL and better scheduler algorithms. The idea that native threads don't scale is a decade out of date. Nowadays, native threads have a lot of advantages-- they are visible to top, renice, and other UNIX utilities; they can be migrated between CPUs effectively by the kernel; and one thread doing I/O does not block other unrelated threads.
Anyway, I'm sure Go could be adapted to use native threads if someone spent some time on it.
> At the very least, channels--which Pike has used before in Alef and
> Limbo--and the segmented stack are really cool.
> The segmented stack solves the issue that has plagued threading (both
> user and kernel scheduled; and in C, Java, et al) and led so many
> people to use event-oriented callback models (myself included), or to
> use interruptible scripting languages like Lua.
The coroutine concept is interesting. Event-driven programming is definitely the way forward for massively multithreaded apps.