Ah ok, I checked the Haiku source and I think this works like the original Binder concurrency stuff (see http://www.osnews.com/story/13674/Introduction_to_OpenBinder...). Android's concurrency framework (as well as Mindroid) is a refined version of Be's concurrency APIs.
Hi that is funny. I knew that Dianne Hackborn brought Binder over to Android from BeOS and Palm. But I did not know that also the concurrency framework is from the Be guys. Thanks for sharing the link :-).
But I have to admit that Android's concurrency framework is more about message passing and actors than about fibers or coroutines. The fiber implementation is much more readable here.
For sure you can rewrite this framework with Go :-).
Mindroid is a framework that makes Actors very handy, like Erlang, Go and some other programming languages also do.
The problem with lthread is that it does not really provide blocking calls inside coroutines (you simply cannot do this with current OSes like Linux or Windows). Just take a look at the docs:
If you need to execute an expensive computation or make a blocking call inside an lthread, you can surround the block of code with lthread_compute_begin() and lthread_compute_end(), which moves the lthread into an lthread_compute_scheduler that runs in its own pthread to avoid blocking other lthreads. lthread_compute_schedulers are created when needed and they die after 60 seconds of inactivity. lthread_compute_begin() tries to pick an already created and free lthread_compute_scheduler before it creates a new one.
It just does the blocking call on its own pthread. That simply does not scale the way Erlang does.
One day there is hopefully an OS where each file, socket, device, etc. is an actor with a message queue. Then you can really be concurrent :-). Even Erlang can then be more concurrent...
From reading source code both for fun and for purpose e.g. like the Android, Minix, QNX, Linux and NetBSD, network protocol stacks, filesystems, web frameworks, CouchDB etc. I got a lot of insights into interesting software technologies and architecture patterns.
Good software engineers and architects should be good and fast at reading code.