Tue Jun 8 00:34:00 CEST 2004
I tried to do the same a couple of years ago. I used Pth as the
It worked pretty well.
In the end I asked myself "Why?" and returned to Erlang.
Happy ever since.
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
More information about the erlang-questions