ErlCee++

[Shawn Pearce]

Sick and twisted; but here goes...

I'm currently working with a client who I think would be better off doing
their development in Erlang - the product is an embedded command and
control system running on x86/Linux hardware - with plenty of memory
and disk space to host a complete OTP environment.  Its semi-realtime,
and since its a control system only, Erlang's runtime wouldn't have an
impact on system performance.  Basically how AXD 301 uses Erlang, but the
product isn't a network/telephony product.  (Its consumer electronics.)

Management just settled on using C++ however as the only development
language.  I had to side with the C++ camp as the only other option being
considered was Java with lots of C++ written in JNI and glued in on the
side.  Erlang was proposed, but since nobody on the full time staff
actually has even heard of Erlang, it was dismissed as "not a viable
solution" without any real consideration.  Perhaps that's the right
move for this group of developers given their attitudes, but I digress.

I'm looking at trying to emulate certain aspects of the Erlang
environment which I think are key to its success, and why I wanted to
use it here.  This would become an "ugly hack" I've termed ErlCee++.

I'm wondering if anyone else on this list who loves Erlang as much as
I do but has been forced to work in pure C++ has attempted this?  I'm
looking at bringing over:

	- one mailbox per concurrent activity

	- selective receive

	- send/receive as the only synchronization primitive allowed
	  (we'll just have to enforce this one through development processes
	   and code reviews)

	- no program globals (only registered processes; also will need to
	  be enforced through development processes and code reviews)

	- "lightweight" processes.  Some of the concurrent activity
	   could actually be modeled through simple callbacks to user
	   code, much how gen_server behaves in Erlang.  Multiple
	   services could share the same heavyweight POSIX thread
	   or UNIX process.  Other concurrent activity however will
	   really need dedicated POSIX threads or UNIX processes;
	   as they will be easier to code that way due to their need
	   for heavy interaction with the OS kernel or the simple fact
	   that they would be easier to program as a preempted thread
	   rather than return/reinvoke.  (I'm thinking the pure Erlang
	   lock server example as one case.)

The downside here is that POSIX threads and UNIX processes cost a lot
more of memory resources and context switch latencies than an Erlang
process costs.  The other is I haven't quite found a nice way to code
selective receive in C++; even with its "awesome and powerful all you
will ever need" templates.

I should make clear I'm not out to rewrite OTP, that's a massive
undertaking that I wouldn't wish on anyone.  I'm just trying to find a
simple way to bring a few key features from Erlang to make development
faster and less painful.  The system has a lot of concurrent activity
that really should be modeled that way; but these developers haven't
quite grasped that one yet, let alone how flawed the "event" system in
Java is when you have a highly concurrent application.

I've spent the past few days doing research into Boost's signals/slots
system, and the Qt signal/slot system with that mess of a precompiler
they call moc...  and its not what I'm looking for.  The Boost signals
library could be used as an underlying feature, but it certainly doesn't
offer selective receive, and isn't a message passing system.  It also
uses a ton of memory for the number of signals/slots we'd need to wire
up.

-- 
Shawn.