DanielHimmelein

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.

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.

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 really like reading source code, that's why I put together some advise how to do it: http://himmele.blogspot.de/2012/01/how-do-you-read-source-co...

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.

Yes, of course :-)

Some more resources about virtual machines and a little TinyVM overview: http://himmele.blogspot.com/2011/08/virtual-machines.html

That's damn right :-)