[wiregate] Plugins: Race-Conditions ?

[emax]

Bei meinem aktuell in Arbeit befindlichen Plugin kam mir soeben mit Schrecken die Befürchtung, dass ich in eine Race-Condition Falle laufen könnte.

Das Problem:

• Ich bediene mit dem Plugin ein gutes Dutzend RTR.
• Der Status eines jeden RTR wird plgun-intern in einem hash namens %Conf zwischen-gespeichert, der am Ende in plugin_info landet
• CODE: $plugin_info{$plugname.'_conf'} = freeze(\%Conf);
• Bei jedem Aufruf des Plugins wird eben dieser Hash wieder aus plugin_info zurückgelesen:
• CODE: %Conf=%{thaw($plugin_info{$plugname.'_conf'})};
• und am Ende dann wieder mit freeze in _conf zurückgeschrieben, usw.

Das funktioniert auch ganz prächtig. Nun ist mir aber jäh bewusst geworden, dass der wiregated ja einen Lauscher-thread fährt, also nebenläufig agiert. Das heißt denn ja wohl, dass das Plugin zwei mal (fast) gleichzeitig laufen kann, wenn denn zwei geeignete Telegramme hintereinader im eiblisten_thread aufschlagen.

Die Konsequenz kann dann wohl sein, dass Folgendes passiert:

1. Telegramm eins kommt an, geht ans Plugin, Instanz 1.
2. Instanz 1 entpackt _conf in den eigenen Hash.
3. Telegramm zwei kommt an, geht ans Plugin, Instanz 2
4. Instanz 2 entpackt _conf ebenfalls in seinen eignen Hash.
5. Instanz 1 ist fertig, schreibt seinen aktualiserten Hash wieder in _conf.
6. Instanz 2 ist kurz danach fertig, und schreibt seinerseits seinen aktualisierten Hash in _conf.
7. Damit sind die Änderungen von Instanz 1 verloren.

Ist das so? Den Begriff "semaphore" habe ich im wiregated nicht gefunden (kann man ja auch nicht unbedingt erwarten). Da wird mehrfach $plugindb->sync() aufgerufen, aber ich habe die Mechanik noch nicht ganz durchschaut.

- Gibts da ein Mittel, 'best practices' oder dergleichen?
- Oder hab ich im wiregated vielleicht was übersehen?

Vielleicht kann makki dazu was sagen. Nein, ich verlange für die Plugins keine thread-safety, war m.W. ja nie vorgesehen. Aber vielleicht gibts ja eine Lösung - oder ich liege sowieso vollkommen falsch, das wäre am Schönsten ;-)

[makki]

Stand makki@2015 kann ich dir das beantworten: es gibt da keinerlei threading(*1) und damit auch keine mögliche concurrency!
Das habe ich zwar seinerzeit monatelang versucht umzusetzen - jedoch mit mässigem Erfolg, weil das multithreading bis heute in Perl einfach komplett broken ist
Das steht so leider nirgends, bis man damit auf die Nase fällt
Der Weg da raus wäre nur eine quasi komplette Neuetwicklung des wiregted als Wrapper um Perl mit C(++) und pthread o.ä. gewesen, die es zwar als rudimentären Prototypen seit damals gibt, es aber nicht zur Serienreife kam.

Die gute Nachricht: da kannst du eigentlich nicht in ein Problem laufen, das läuft alles sequentiell in einem Prozess und einem Thread.

Makki

(ich weiss *nicht* ob sich das seit 2015 geändert hat! schätze aber eher nicht.. weil die einzige Lösung wäre eine komplett umgebaute Runtime für die Plugins)

Edit: im source könnte man denken, das threading stattfindet, war ja auch vorgesehen; ist aber nicht so..

[emax]

Vielen Dank, makki! Das hilft mir weiter und beruhigt mich ungemein :-)