[Allegro] a30 / Parallelen zwischen FLEX und JOB

[Thomas Berger]

Lieber Herr Eversberg,

>> Sie haben allerdings den String ex, der nur geringfuegig kleiner als
>> die iV ist, als allgemeines Scratchpad? Wenn Sie "inpu" nicht starr
>> fuer die iV benutzen, sondern als Pointer auf abwechselnd einen von
>> zwei gleich grossen Bereichen (aktuelles / naechstes), duerfte das
>> viele Probleme loesen...
>>
> Theoretisch, in praxi aber äußerst wenige.
> 
> Wird mit langen Inhalten hantiert, ist generell Um- und Vorsicht
> geboten. Bibliographische Datensätze, und allemal Katalogdatensätze,
> sind in diesem Sinne kaum jemals "lang"; auch MARC und Pica haben
> ihre bei 10.000 liegenden Grenzen der SATZlänge, nicht FELDlänge!

Zumindest bei MARC21 ist die Grenze 99.999 (5 Ziffern, nicht 10^5),
evtl. abzueglich Directory. Jedenfalls ziemlich gering wenn man
bedenkt, dass der Anspruch besteht, auch Abstracts und Inhalts-
verzeichnisse im Volltext transportieren zu koennen.


[...]

> FLEX als Skriptsprache hat, wie jede echte Programmiersprache auch,
> ihre Tücken. Die ernsteren davon liegen real nicht in solchen Dingen,
> sondern in der Gefahr der Schleifenbildung, die mit keinem Mittel und
> in keiner Sprache verhütbar ist. In acon haben wir da immerhin einen
> einstellbaren Zähler, der eine Endlosschleife irgendwann mit Fehler-
> meldung abbricht. Ob z.B. Java sowas hat, weiß ich nicht, C jedenfalls
> hat es nicht. C und C++ bergen ferner die sehr reale Gefahr der

Linux als Laufzeitumgebung fuer reale Programme kennt alarm, Windows
hat m.W. so etwas auch (Womit wir beim anderen Thema der un-Windows-
maessig einfrierenden a99-Fenster bei Global-Operationen waeren).


> Bereichsüberschreitung, die zwar vom Betriebssystem i.a.R. abgefangen
> wird, aber leider nur mit einer hilflosen Absturzmeldung. So etwas kann

und erst dann, wenn es "wirklich heftig" war. Eine "kleine" Entgleisung,
die nur Speicherbereiche innerhalb des Programms selbst betrifft, wird
i.d.R. nicht bemekrt, bzw. nur indirekt, wenn das Programm wegen
inkonsistenter Daten zu vandalieren beginnt. Man kann dann wirklich
froh sein, wenn es schnell abstuerzt und nicht insgeheimen Schaden
anrichtet...


> nur Vor- und Umsicht beim Programmieren abmildern. Wie bei FLEX.

Weil mit C die Programmiersprache FLEX implementiert ist und dafuer
eine Laufzeitumgebung bereitstellt, ist besondere Vorsicht geboten:
Man darf nicht davon ausgehen, dass der Flex absolut korrekt
programmiert ist. Wenn konkret im Flex ein isoliertes

sleep

steht, dann ist das zur Laufzeit nur dann korrekt, wenn in der
iV eine Zahl steht (denn Sleep bekommt Zahlen als Argument), und
es gelten vermutlich auch noch harte Nebenbedingungen fuer diese Zahl
(als 64bit-Integer darstellbar? [Fragen zur Sinnhaftigkeit grosser
Zahlen, etwa Beruecksichtigung des erwarteten Zeitpunkts fuer den
Waermetod des Universums, des Supernova-Ereignisses im Sonnensystem,
vorhersagbare Crashs des Betriebsystems beim Datumsueberlauf, Renten-
Eintrittsalter des Bearbeiters, Lebensdauer von Rechnern, Mittagspause
sind fuer sich keine eigenen Nebenbedingungen, sondern nur Rechtfertigung
und Motivation fuer die implementierten]).

Der Bearbeiter vor dem Schirm hat hier moeglicherweise eine problematische
Vorbelegung veranlasst (wer hatte noch nie einen Cut&Paste-Unfall?), und
diesen Fall /haette/ bereits der Flex-Programmierer im Prinzip abfangen
muessen. Hat er aber nicht (weil er selber noch testet, oder weil er dem von
Skriptsprachen allgemein suggerierten Versprechen zu besonders sorgenfreier,
laessiger und "spontaner" Programmierung geglaubt hat). Jedenfalls hat die
Laufzeitumgebung die doppelte Aufgabe, sowohl den Rest des Systems zu schuetzen
als auch dem Bearbeiter oder Flex-Programmierer moeglichst zielgenaue Hinweise
auf eine Fehlfunktion rueckzumelden (aber auch nicht mehr: Der Flex muss nicht
interpretierend um jeden Preis zu einem "sinvollen" Ende gebracht werden und
Kommentare des Programms zur Sinnhaftigkeit eines hundertjaehrigen sleep sind
ebenfalls unerwuenscht, es sei denn sie sind konfigurierbar).

D.h. selbst wenn die Entwicklungsabteilung selbst bekanntermassen nicht einem
defensiven Programmierstil zuneigt, die Laufzeitumgebung fuer FLEX muss auf
wirklich alles gefasst sein (insbesondere auf mehr als das Antizipierbare ;-).


> Wie in jedem Programmiersystem muß man auch bei FLEX Aufwand und
> Effekt mit Augenmaß ins Verhältnis setzen. Unverhältnismäßig wäre in
> diesem Sinne, einen zusätzlichen Bereich von 4MB vorzuhalten, der nur
> in äußerst wenigen, mit ein wenig Bedacht beim FLEXen vermeidbaren
> Situationen ein Problem entschärfen würde. Bergers an sich natürlich

Es ist in der Praxis selbst bei Trivialprogrammen ("hello world!") unmoeglich,
diese im ersten Anlauf so perfekt auszudenken /und/ hinzuschreiben, dass Tests
mit Sicherheit ueberfluessig sind. "Mit Bedacht" kann erst das /Resultat/
gruendlichen Testens sein und die Laufzeitumgebung hat dabei die Aufgabe zu
helfen, nicht zu verschleiern!

Und der Aufwand eines spezifizierbaren Mehrverbrauchs an Arbeitsspeicher
und CPU-Verbrauch ist selbst mit tausenden von Installationen
multipliziert nichts im Vergleich zu dem Effekt, dass auch nur ein einziger
Flex-Programmierer dadurch einen sonst unbemerkt gebliebenen oder erst nach
vielstuendigen Tests gefundenen Fehler in seinem Flex findet. (Es geht
eigentlich gar nicht darum, einen Aufwand mit einem Effekt in Beziehung
zu setzen, sondern darum, fuer den vorgegebenen Minimaleffekt eines
funktionsfaehigen Programms den Aufwand an dieser Stelle in Beziehung
zu setzen mit dem Aufwand, der ansonsten an vielen(!) anderen Stellen
zu leisten ist)

Und falls Speicherverbrauch und Performance da wirklich ein Problem sind
(woran ich nicht glaube: Spaetestens mein Rechner vom naechsten Jahr
macht das wieder wett, wir reden ja nicht von zusaetzlichen Platten-
oder Netzwerkzugriffen), dann muss halt eine "Sandbox" fuer Flexe und
Jobs her, die dann eine dedizierte Testumgebung darstellen wuerde.

viele Gruesse
Thomas Berger