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.

Yes, it is like the original Be code. It was for showing the inheritage.

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.

Cool, looks much better :-). Normally, I really like Android's concurrency abstractions, but not for this one :-).

Oh, you are right with quitter. That is a typo. It will fix it. It used chan string just because it does not matter for this example :-).

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.

I was making fun of the recent blather going on about Go and concurrency of late.

I am pleased it's in C++.

Quickdroid can also search for abbreviations. You just have to enable this in the settings. It is not activated by default.

Maybe you can do the same thing as the Nexus Q and even more using your Android handset and a 35$ Raspberry Pi: Check out the Android Transporter: http://esrlabs.com/android-transporter-on-the-raspberry-pi/

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...

I wrote the docs. :) . It really does provide blocking calls inside a coroutine. The coroutine can totally block on a non-socket resource (CPU calculation, disk IO in case you aren't using aio) without effecting other coroutines.

I do agree that actor models implemented at the OS level is much cleaner, but when it comes to CPU hogging sections, messages queues are not the answer.