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

[Joe Armstrong]

On Wed, Oct 5, 2011 at 12:38 AM, Richard O'Keefe <ok@REDACTED> wrote:
> 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.

Absolutely - move compliance into the software - If traders expose a
bank to too much risk the
trades should be stopped automatically. This might have prevented
(say) the collapse
of Baring bank. There is a trade of between security - (we have to
spend a few CPUs cycles
checking for illegality) and speed here.

If a bank collapses due to trading violations that could have been
detected by software and no
such software was in place I imagine legal action could be taken. So
there should be a strong argument for such software.

/Joe







> 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.
>
>