[erlang-questions] Keeping massive concurrency when interfacing with C

[Richard O'Keefe]

A further clarification on what Joe wrote about hot loading:

 Whatever the current Erlang system actually does, the overhead of remote
 calls need in principle be no more than the overhead of dynamic dispatch
 in a language like C++.

 That overhead is actually surprisingly high (and yet people *willingly*
 write Java, go figure).  There is an indirect cost to the indirection,
 namely that dynamic calls can't be inlined.  For C++ there is an answer:
 link-time analysis can find calls (often lots and lots of them) that
 don't actually need to be polymorphic (e.g., because the declared class
 turns out not to have any subclasses that override the method in question)
 and those calls can be inlined after all.  In languages which allow new
 code to be added at run time (like Java and Erlang) it's not that easy.

Some years ago I proposed that Erlang could distinguish between
"detachable" and "non-detachable" parts, so that a group of modules could
be bound together in such a way that they would have to be replaced _as a
unit_.  The idea has not been taken up because it's very far from being
Erlang's most pressing problem.

To John Smith, what on earth does "shocking the yield curve" mean?


One thing about architecture.  Joe raised an interesting question.
"Now suppose you discover a fault in your software that causes to you
buy or sell shares at a catastrophically bad rate - what do you do -
wait for everything to stop before changing the code?"

My question is, "how could you structure your system so that if it
TRIES to buy or sell at a catastrophically bad rate it CAN'T?"  A couple
of years ago I came up with an idea for a potential PhD candidate who
ended up going somewhere else.  That was inspired by a true event here,
where an electricity company cut off supply to a house where there was
an extremely sick woman who depended on some machine to keep her alive
(I forget what kind).  Needless to say, she died.  And of course it was
one of those stories where the computer noticed the bill hadn't been
paid recently and sent out a notice to a technician who dutifully went
out and turned the power off without asking any awkward questions.  So
what can we do to stop that?  (The customer had informed the company of
their special needs.)  The answer I came up with turns out to be
quite similar in spirit to Joe's UBF.

	You have a GENERATOR of actions,
	a CRITIC of actions, and
	an EFFECTOR of actions.

(Come to think of it, there's a link here to Dorothy L. Sayers' "The
Mind of the Maker.")  The generator of actions receives inputs and
decides on things to do, but doesn't actually do them.  It passes
its proposals on to the critic, which watches out for bad stuff.
Things that the critic is happy with are passed on to the effector to
be carried out.

In the electricity case, the critic would use rules like
	"If the proposal is to disconnect supply
	 and the customer has registered a special need
	 and there is no record of a court order
	 REJECT"

In the trading case, the critic's rules would say something about the
amount of money.

The generator should not rely on the critic; if everything is working
well you won't be able to tell if the critic is there or not.

A rejection by the critic indicates an error in the generator
requiring corrective programming.  This is where it gets similar
to UBF:  UBF contract checking isn't there to make good things
happen normally, it's there to stop bad things happening and make
sure they're noticed.

This is one way to use multicore: spend some of the extra cores doing
more checking.