Es geht nach wie vor nicht um den Vergleich zwischen "dynamic loading" und "code hot swapping", was Du immer wieder in den Thread hineininterpretierst. Ich beziehe mich nach wie vor auf das geänderter Code kann zur Laufzeit neu geladen werden. Code, der gerade aktiv ausgeführt wird, darf natürlich nicht überschrieben werden. Das wäre selbst modifizierender Code, was aufgrund des damit verbundenen Sicherheitsrisikos auf aktuellen Systemen vermieden wird. Unter *DOS war dies durchaus üblich. Aber Code einer Bibliothek, die zum Beispiel gerade in der Entwicklung befindlich ist, kann unter geeigneten Randbedingungen durchaus im laufenden Programm ersetzt werden. Man könnte auf diese Weise dann auch beliebigen Code einfügen, aber das liefe dann wohl eher unter der Rubrik „Schadsoftware“. Allerdings lässt sich eine Funktionalität, wie zum Beispiel aktualisieren ohne es neustarten zu müssen unter geeigneten Randbedingungen, wozu auch die Sicherung der für den Betrieb notwendigen Informationen außerhalb des shared objects gehören, umsetzen. Ich wiederhole aber dennoch: Du versuchst hartnäckig mir die Behauptung "dynamic loading" sei "mindestens so mächtig, wie code hot swapping" unterzuschieben. Das ist ein für einen Troll typisches verhalten.
Es geht nach wie vor nicht um den Vergleich zwischen "dynamic loading" und "code hot swapping", was Du immer wieder in den Thread hineininterpretierst. Ich beziehe mich nach wie vor auf das geänderter Code kann zur Laufzeit neu geladen werden.
Dann habe ich Sie und kamome umidori missverstanden. Um das aufzuklären: der Link oben enthält Folgendes:
Hot-reloading is a technique that allows for rapid iteration during the development of an application.
The core idea is that by encapsulating core logic in dynamic libraries, and then carefully managing application state, we can reload a newly compiled library while the application continues to run and have changes take immediate effect. [...] In this approach to hot-reloading, libaries must contain no internal state. All state needed by the hot-reloaded libraries is declared outside of the libraries, owned by the application and then passed into each library function call.
This means that you can simply reload the library while the game is still running, and have your game update live. As a consequence however, you can't have any global state in your library, everything must be owned by the host in order to avoid getting unloaded with the library.
Diese Form des "hot/live reloading" wäre natürlich mit den POSIX-Aufrufen für "dynamic loading" abgedeckt. Da haben Sie Recht.
Code, der gerade aktiv ausgeführt wird, darf natürlich nicht überschrieben werden.
Ja, das ist natürlich eine wichtige Einschränkung, die wir lang und breit diskutierten.
Das wäre selbst modifizierender Code, was aufgrund des damit verbundenen Sicherheitsrisikos auf aktuellen Systemen vermieden wird.
Einige JIT-Compiler tun dies bspw., aber es müsste nicht unbedingt selbstmodizierender Code sein, das wäre lediglich ein Spezialfall. Bei "code hot swapping" z.B. modifiziert sich der Code nicht zwingend selbst.
Aber Code einer Bibliothek, die zum Beispiel gerade in der Entwicklung befindlich ist, kann unter geeigneten Randbedingungen durchaus im laufenden Programm ersetzt werden.
Ja, richtig: unter geeigneten Randbedingungen, z.B. an den Programmzustand und dessen Verwaltung, wie ich oben bereits andeutete.
Allerdings lässt sich eine Funktionalität, wie zum Beispiel aktualisieren ohne es neustarten zu müssen unter geeigneten Randbedingungen, wozu auch die Sicherung der für den Betrieb notwendigen Informationen außerhalb des shared objects gehören, umsetzen.
Genau, aber eben nur, wenn man entsprechende Vorkehrungen trifft, bevor das Programm läuft.
Du versuchst hartnäckig mir die Behauptung "dynamic loading" sei "mindestens so mächtig, wie code hot swapping" unterzuschieben.
So hatte ich Ihre Aussagen aber nun einmal verstanden gehabt. Tut mir Leid, aber Missverständnisse geschehen mitunter, auch ganz ohne verwerflich Absichten. Schön, dass wir das nun wissen.
> Ich wiederhole aber dennoch: Du versuchst hartnäckig mir die Behauptung "dynamic loading" sei "mindestens so mächtig, wie code hot swapping" unterzuschieben. Das ist ein für einen Troll typisches verhalten.
Der Verdacht drängt sich allerdings auf. Ich kann die Absichten zwar noch nicht sicher verorten, tippe aber auf eine politische Motivation. Mit der Zeit wird das sicher deutlicher.
Es geht nach wie vor nicht um den Vergleich zwischen "dynamic loading" und "code hot swapping", was Du immer wieder in den Thread hineininterpretierst. Ich beziehe mich nach wie vor auf das geänderter Code kann zur Laufzeit neu geladen werden. Code, der gerade aktiv ausgeführt wird, darf natürlich nicht überschrieben werden. Das wäre selbst modifizierender Code, was aufgrund des damit verbundenen Sicherheitsrisikos auf aktuellen Systemen vermieden wird. Unter *DOS war dies durchaus üblich. Aber Code einer Bibliothek, die zum Beispiel gerade in der Entwicklung befindlich ist, kann unter geeigneten Randbedingungen durchaus im laufenden Programm ersetzt werden. Man könnte auf diese Weise dann auch beliebigen Code einfügen, aber das liefe dann wohl eher unter der Rubrik „Schadsoftware“. Allerdings lässt sich eine Funktionalität, wie zum Beispiel aktualisieren ohne es neustarten zu müssen unter geeigneten Randbedingungen, wozu auch die Sicherung der für den Betrieb notwendigen Informationen außerhalb des shared objects gehören, umsetzen.
Ich wiederhole aber dennoch:
Du versuchst hartnäckig mir die Behauptung "dynamic loading" sei "mindestens so mächtig, wie code hot swapping" unterzuschieben. Das ist ein für einen Troll typisches verhalten.
who knows
Schön, dass wir das nun wissen.Naja, ich weiß nicht...
Machen Sie's gut!
> Ich wiederhole aber dennoch:
Du versuchst hartnäckig mir die Behauptung "dynamic loading" sei "mindestens so mächtig, wie code hot swapping" unterzuschieben. Das ist ein für einen Troll typisches verhalten.
Der Verdacht drängt sich allerdings auf. Ich kann die Absichten zwar noch nicht sicher verorten, tippe aber auf eine politische Motivation. Mit der Zeit wird das sicher deutlicher.