We’ve been having some interesting discussions on the Hecl mailing list about how to do concurrency:

http://sourceforge.net/mailarchive/message.php?msg_id=19566676

(although it seems SF has managed to lose a portion of the conversation!)

When all things are said and done, we have a couple of options:

• Try and immitate Tcl’s select-based event loop. Not really concurrency, but it does a good job of “faking it” for things like GUI’s, if done correctly. For the right kind of code, it makes life very easy for the programmer, as you don’t have to think too much about concurrency issues, and you don’t have to deal with threads. The downside for J2ME is that we don’t have the equivalent of select, so we’d have to do the system with threads, which would probably be costly in terms of the resources required to set it up.

• Tcl style threads, where each thread gets its own interpreter, and data is mostly shared by message passing between the threads. Conceptually, I think this is a cleaner way of doing threads, compared with ‘sharing everything and using mutexes’, and it’s a little closer to how Erlang handles concurrency, which is very nice indeed. For J2ME, I’m a little bit worried that this might be too resource intensive, and potentially slow to launch new threads.

• A low-level interface to threads that just exposes the Java API. This would be nice, and lightweight, but potentially quite complex to program if we attempt to make the interpreter reentrant. There are a lot of issues with things like stack frames – for instance, say one subroutine (proc) adds a stack frame, then a second thread kicks in and exits a proc, tearing down the stack frame again. If you put a big lock around procs, that just leads to blockage if a proc is doing some sort of long running calculation, defeating the whole point of the exersize.

• Deal with concurrency on a case-by-case basis, building it into each command that needs it. Not very elegant, and probably requires just as much work, if not more, than other options.

At this point, I’m tending towards each thread having an interp, because option three seems very prone to extremely difficult bugs. Not sharing the interpreter has worked well for Tcl both from the implementation and end user perspectives. It is, however, not an easy subject and I’m still thinking about it.

Note comments are broken, so email me with questions or comments.