[erlang-questions] Frying pan bug

[Richard O'Keefe]

On 3/03/2012, at 3:42 AM, David Goehrig wrote:

> I'm curious, I know that people are "right" when they say fix validate the inputs to factorial, but there are equations far less well known with similar degenerate cases where writing guards are inexpressible due to there being an infinite number of degenerate points.  Not all curves are continuous even in the real world.

In fact the negative integers are the only points on the real line where factorial is
undefined.  There are, however, an infinite number of them, and that doesn't mean that
guards are inexpressible.

> Would it be possible for Erlang's runtime to set a threshold, say looking at the thermal sensor on the board and error out if that "guard" is reached.

There is no guarantee
 - that the 'board' *has* a thermal sensor (if there is a thermal sensor on the Sun-Blade 100 I
   still use, that can be read by user-level code, I would be interested to hear about it)
 - that the thermal sensor can be read by user code
 - that an infinite loop will cause the temperature to rise appreciably
 - that some component of the system will not detect a rise and respond by
   reducing clock speed so the rise stops
 - that a temperature rise is caused by *this* process rather than some other process
 - that the readings are reliable.

I just tried it on a Mac.  "CPU A Temperature Diode" was initially at 32C.
Running fac(-1), it rose over a couple of minutes to 38C, and then fell back to
34C, where it remained.  Bearing in mind that the "Northbridge Chip" was at 59C
and remained there, that doesn't sound like the kind of huge rise that you would
expect to trigger alarms.  Come to think of it, a 2C rise doesn't sound much
like a frying pan either.  Considering how thin the Mac is, and where it is
placed, I'd be surprised if I couldn't get a similar effect by turning on the
office heater.

I mention the possible unreliability of the readings because the same software can
monitor things like power consumption, and those results are completely crazy.
(Wrong signs, for example...)

> You could do the same for disk I/O, network, or any other saturation condition.

I have programs that saturate I/O without anything being wrong.

> This has been recently on my mind as we just did a poorman's thermal chamber test, and I've been writing a lot of Erlang that monitors the behavior of other apps under environmental stress, but have yet to solve the "how does the monitor that monitors itself know when to throw up the white flag and surrender?"

I've been reading about self-stablising systems lately, and the rock bottom answer seems
to be "watchdog timers".  A watchdog timer would certainly have caught this.