softhddevice bug ( X Speicherzugriff auf VDR )

Richtiger und besserer Stil wäre es gewesen das im zugehörigen Bugtracker zu melden: http://projects.vdr-developer.…s/plg-softhddevice/issues

Oder per PN an den Autor ...

Regards
fnu

Naja, Du hast ja eine sehr konkrete Vermutung, die tütet man dann auch direkt entsprechend ein.

Wie dann die Fehlerbehebung auch immer am Ende aussieht, ich vermute "johns" hatte Grund hier "vfork" zu nutzen, bisher hat diesen Umstand wohl noch niemand sonst gemeldet.

Wenn Du noch nicht gewusst hättest wo das Probleme liegt und Diskussionspartner dazu gesucht hättest, wäre das schon hier richtig gewesen.

Regards
fnu

Im Prinzip ist es egal wo der Fehler gemeldet wird, im vdr-developer geht er halt nicht unter.

Wobei ich das ganze Problem noch nicht verstehe. Laut man-page soll man vfork verwenden, wenn
man exec macht.

Das hier:

// close all open file-handles
    maxfd = sysconf(_SC_OPEN_MAX);
    for (fd = 3; fd < maxfd; fd++) {    // keep stdin, stdout, stderr
        close(fd);                      // vdr should open with O_CLOEXEC
    }

schliesst alle Filehandle. Dies ist zusätzlich dazugekommen und war in meiner ursprünglichen Version nicht.
Dies gefällt mir nicht und ist die Holzhammermethode.

Trotzdem close ist ein Systemcall und greift auf keinen Speicher zu.
Kann es sein das Sundtek den Systemcall "close" umlenkt?

Ich empfehle X selber zustarten und nicht über das Plugin.

Johns

Wir haben ja Applikationsbasierte Treiber, open/close wird beim Frontend umgelenkt, und dort wird ein "Accounting" für die Zugriffe gemacht.
Das Accounting wird natürlich im Speicher abgelegt. Nun teilen sich beide Prozesse mit vfork() den Speicher (wie bei Threads). Demnach schliesst der 2. Prozess dann in diesem Fall das Frontend für den ersten Prozess.
Dennoch um Problemen aus dem Weg zu gehen würde ich im Allgemeinen eher fork() verwenden, wer weiss ob es da nicht nach einiger Zeit eine Änderung gibt und das jemand wieder vergisst.
Die Performanceunterschiede sind für einen Menschen an der Stelle auch nicht nachvollziehbar, wohl eher im Nanosekundenbereich.

Dann wird die Sache klarer.

open und close umändern ist zwar nicht sauber und schlecht für die Performance.
Aber dies ist nicht meine Baustelle.

Ich werde demnächst den "vfork" in "fork" abändern.

Johns

Die open/close Performance ist ziemlich nebensächlich, alles was im Nanosekundenbereich liegt ist vernachlässigbar, selbst auf den langsamsten embedded Krücken ist das nicht spürbar, ausserdem ist das ohnehin nur bei Frontend/DVR Zugriffen anders.
Dafür werden die Daten bei uns zwischen Treiber und Applikation mit Shared Memory Segmenten übertragen was dann wieder einiges an Kopiererei spart.
Danke das du das trotzdem abänderst