ErlCee++

[Joakim G.]

I tried to do the same a couple of years ago. I used Pth as the
core.

http://www.gnu.org/directory/pth.html

It worked pretty well.

In the end I asked myself "Why?" and returned to Erlang.

Happy ever since.

/Jocke

Shawn Pearce wrote:
> 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.
>