generic dop: Dateidownload - mehrere Prozesse

Hallo,
ein Prozess (a) lädt eine große Datei und nutzt diese anschließend. Ein anderer Prozess (b) möchte diese Datei ebenso nutzen, muss aber warten, bis a diese _vollständig_ runtergeladen hat.

Nun könnte a ein StatusFlag in einer DB setzen, um Auskunft darüber zu geben, ob die Datei vollständig geladen wurde. b frägt diesen Status solange ab, bis der Status aussagt, dass die Datei nun vollständig vorliegt.

Welche (zuverlässigen) Möglichkeiten gibt es noch? Ich meine jetzt nicht, eine DB durch eine Textdatei zu ersetzen oder ähnliches. Wichtig: es gibt keine Prüfsumme. Kann ein Prozess überhaupt feststellen, ob eine Datei vollständig geladen wurde?

  1. Hi,

    ein Prozess (a) lädt eine große Datei und nutzt diese anschließend. Ein anderer Prozess (b) möchte diese Datei ebenso nutzen, muss aber warten, bis a diese _vollständig_ runtergeladen hat.

    erklär doch bitte mal genauer.
     * Laufen die Prozesse auf demselben Host?
     * Haben sie beide direkten Dateizugriff?
     * Von wo nach wo wird die "große Datei" geladen?

    Welche (zuverlässigen) Möglichkeiten gibt es noch? Ich meine jetzt nicht, eine DB durch eine Textdatei zu ersetzen oder ähnliches. Wichtig: es gibt keine Prüfsumme. Kann ein Prozess überhaupt feststellen, ob eine Datei vollständig geladen wurde?

    Ja, über Dateisperren (file locking). Prozess a liest oder schreibt die Datei (das geht aus deiner Beschreibung leider nicht hervor), hat sie also für eine gewisse Dauer geöffnet. Wenn der gleichzeitige Zugriff mehrerer Prozesse so heikel ist, sollte die Datei währenddessen für andere Prozesse vollständig gesperrt werden. Dann braucht's keine weiteren Metainformationen.

    So long,
     Martin

    --
    Wissen erwirbt man, indem man immer das Kleingedruckte sorgfältig liest.
    Erfahrung bekommt man, indem man das nicht tut.
    Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
    1. Hallo Martin,

      ein Prozess (a) lädt eine große Datei und nutzt diese anschließend. Ein anderer Prozess (b) möchte diese Datei ebenso nutzen, muss aber warten, bis a diese _vollständig_ runtergeladen hat.

      erklär doch bitte mal genauer.
      * Laufen die Prozesse auf demselben Host?
      * Haben sie beide direkten Dateizugriff?
      * Von wo nach wo wird die "große Datei" geladen?

      Ja, die Prozesse laufen beide (können auch viele sein) auf demselben Host. Sie haben auch alle direkt Dateizugriff. Die große Datei (> 1 GB) wird von einem remote server auf den lokalen Host geladen, und zwar via ftp oder http, selten ssh. Es handelt sich also um Zugriff auf das Dateisystem und nicht um einen Datenbankzugriff.

      Welche (zuverlässigen) Möglichkeiten gibt es noch? Ich meine jetzt nicht, eine DB durch eine Textdatei zu ersetzen oder ähnliches. Wichtig: es gibt keine Prüfsumme. Kann ein Prozess überhaupt feststellen, ob eine Datei vollständig geladen wurde?

      Ja, über Dateisperren (file locking). Prozess a liest oder schreibt die Datei (das geht aus deiner Beschreibung leider nicht hervor), hat sie also für eine gewisse Dauer geöffnet. Wenn der gleichzeitige Zugriff mehrerer Prozesse so heikel ist, sollte die Datei währenddessen für andere Prozesse vollständig gesperrt werden. Dann braucht's keine weiteren Metainformationen.

      Prozess a lädt die Datei erstmal auf die Platte, schreibt sie also... Wenn er (der Prozess) sie nach dem Speichern lesend öffnet, brauche ich ja die Sperre nicht mehr.

      File Locking... ok. Was passiert, wenn Prozess a den Download aus welchen Gründen auch immer nicht beendet hat? Wäre nicht die Metainformation wichtig, wie lange der Download nun schon dauert? Der Zugriff ist heikel, die Prozesse könnten überhaupt nicht laufen, wenn ihnen die Datei fehlen würde.

      1. Hello,

        File Locking... ok. Was passiert, wenn Prozess a den Download aus welchen Gründen auch immer nicht beendet hat? Wäre nicht die Metainformation wichtig, wie lange der Download nun schon dauert? Der Zugriff ist heikel, die Prozesse könnten überhaupt nicht laufen, wenn ihnen die Datei fehlen würde.

        Das hängt von der Verbindungsart ab.
        FTP ist verbindungs- und damit (teilweise) auch zustandsorientiert. Welche Zustände sich abfragen lassen, hängt von der FTP-Implementation ab.

        Aber zumindest sollte man beim FTP-Server konfigurieren können, dass Prozesse, die Dateien benutzen (lesen), zumindet ein shared Lock setzen. Dieser kann dann aber  z.B. auf unixoiden Systemen mit antiquierten Dateisystemen oder Administratoren auch nur "advisory" sein, also nicht verbindlich. Es müssten sich demnach alle Prozesse an das Locking-Szenario halten.

        Anders ist das, wenn man das Dateisystem mit dem Zusatz Mandatory (mand) gemountet hat. Dann kann man auch die neueren mandatorischen Sperren (wie bei WINDosen üblich) nutzen. Daran kommt dann kein Prozess, der nicht das OS selbst (oder dessen relevante Treiber) ersetzt, mehr vorbei.

        Auch ein FTP-Server muss ich dann daran halten, wenn ein anderer Prozess eine mandatorische Sperre gesetzt hat. Ggf. funktioniert der FTP-Server dann aber gar nicht erst... *ohoh*

        Liebe Grüße aus dem schönen Oberharz

        Tom vom Berg

        --
         ☻_
        /▌
        / \ Nur selber lernen macht schlau
        http://bikers-lodge.com
        1. Hallo Tom,

          File Locking... ok. Was passiert, wenn Prozess a den Download aus welchen Gründen auch immer nicht beendet hat? Wäre nicht die Metainformation wichtig, wie lange der Download nun schon dauert? Der Zugriff ist heikel, die Prozesse könnten überhaupt nicht laufen, wenn ihnen die Datei fehlen würde.

          Das hängt von der Verbindungsart ab.
          FTP ist verbindungs- und damit (teilweise) auch zustandsorientiert. Welche Zustände sich abfragen lassen, hängt von der FTP-Implementation ab.

          Aber zumindest sollte man beim FTP-Server konfigurieren können, dass Prozesse, die Dateien benutzen (lesen), zumindet ein shared Lock setzen. Dieser kann dann aber  z.B. auf unixoiden Systemen mit antiquierten Dateisystemen oder Administratoren auch nur "advisory" sein, also nicht verbindlich. Es müssten sich demnach alle Prozesse an das Locking-Szenario halten.

          Anders ist das, wenn man das Dateisystem mit dem Zusatz Mandatory (mand) gemountet hat. Dann kann man auch die neueren mandatorischen Sperren (wie bei WINDosen üblich) nutzen. Daran kommt dann kein Prozess, der nicht das OS selbst (oder dessen relevante Treiber) ersetzt, mehr vorbei.

          Auch ein FTP-Server muss ich dann daran halten, wenn ein anderer Prozess eine mandatorische Sperre gesetzt hat. Ggf. funktioniert der FTP-Server dann aber gar nicht erst... *ohoh*

          danke, damit muss ich mich erstmal auseinandersetzen.

      2. Hallo,

        erklär doch bitte mal genauer.
        * Laufen die Prozesse auf demselben Host?
        * Haben sie beide direkten Dateizugriff?
        * Von wo nach wo wird die "große Datei" geladen?
        Ja, die Prozesse laufen beide (können auch viele sein) auf demselben Host. Sie haben auch alle direkt Dateizugriff. Die große Datei (> 1 GB) wird von einem remote server auf den lokalen Host geladen, und zwar via ftp oder http, selten ssh. Es handelt sich also um Zugriff auf das Dateisystem und nicht um einen Datenbankzugriff.

        gut, jetzt habe ich also eine ungefähre Vorstellung.

        Prozess a lädt die Datei erstmal auf die Platte, schreibt sie also... Wenn er (der Prozess) sie nach dem Speichern lesend öffnet, brauche ich ja die Sperre nicht mehr.

        Sehe ich auch so. Nur sollte Prozess a die Datei, wenn er sie erzeugt bzw. schreibt, auf jeden Fall gegen andere Zugriffe sperren. In der Phase ist eventuell sogar eine Sperre gegen ein weiteres Öffnen zum Lesen sinnvoll, denn Prozess b (c, d, e ...) würde ja dann unvollständige und dadurch möglicherweise ungültige Daten lesen.

        File Locking... ok. Was passiert, wenn Prozess a den Download aus welchen Gründen auch immer nicht beendet hat?

        Kommt drauf an. Solange Prozess a immer noch läuft, auch wenn der Download vielleicht unkontrolliert abgebrochen wurde, kann die Datei geöffnet und die Sperre noch bestehen bleiben. Spätestens wenn Prozess a endet, räumt aber das Betriebssystem hinter ihm her, schließt seine offenen File-Handles und löst ggf. noch bestehende Sperren auf.

        Normalerweise sollte das Programm aber so gestrickt sein, dass es das bei Übertragungsfehlern sofort selbst tut. Es wäre zu überlegen, ob nach einem fehlerhaften bzw. unvollständigen Download die partiell vorhandenen Daten wieder gelöscht werden (dann sollte Prozess b aber die (Nicht-)Integrität an bestimmten Merkmalen erkennen) oder einfach halbfertig liegenbleiben (kann für eine Fehleranalyse vorteilhaft sein).

        Wäre nicht die Metainformation wichtig, wie lange der Download nun schon dauert?

        Ist diese Information denn nötig oder gewünscht? Sobald Prozess feststellt, dass die Datei gesperrt ist, könnte er den zugehörigen Verzeichniseintrag lesen und nach dem Creation Timestamp schauen. Und bekommt über den Quotient aus momentaner Dateigröße und verstrichener Zeit seit dem Anlegen auch die Übertragungsrate, falls das jemand wissen will. Falls die endgültige Dateigröße bekannt ist, kann man daraus sogar eine Schätzung ableiten, wie lange es noch dauern wird.
        "Papa, wann sind wir endlich daaa?" ;-)

        Der Zugriff ist heikel, die Prozesse könnten überhaupt nicht laufen, wenn ihnen die Datei fehlen würde.

        Das ist schlecht. Programme sollten immer so robust ausgelegt sein, dass sie auf vorhersehbare Fehler (und das wäre so einer) sinnvoll und kontrolliert reagieren.

        So long,
         Martin

        --
        Abraham sprach zu Bebraham: Kann i mal dei Cebra ham?
        Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
        1. Hello,

          Sehe ich auch so. Nur sollte Prozess a die Datei, wenn er sie erzeugt bzw. schreibt, auf jeden Fall gegen andere Zugriffe sperren. In der Phase ist eventuell sogar eine Sperre gegen ein weiteres Öffnen zum Lesen sinnvoll, denn Prozess b (c, d, e ...) würde ja dann unvollständige und dadurch möglicherweise ungültige Daten lesen.

          Übliche Locking-Mechanismen arbeiten immer so, dass es zwei Stufen der Sperre gibt:

          • shared lock: der eigene Pozess kann nur lesen, andere können lesen
              und ebenfalls shared locks setzen auf die Datei

          • exclusive lock: der eigene Prozess kann lesen und schreiben, andere können weder lesen,
              noch schreiben, noch locks setzen.

          Wenn ein Prozess vor hat, Daten zu verändern, muss er die exclusive Sperre bereits zum Lesen setzen, um keine Gültigkeitslücke entstehen zu lassen.

          In verbindungsorentierten Systemen werden Datei- und Datensatzsperren i.d.R. automatisch aufgehoben, wennn das _Handle_ auf die Datei ungültig wird, also der Prozess endet oder stirbt.

          Da es mWn heutzutage keine Filesysteme mehr gibt, die noch mit FCBs (File Control Blocks) arbeiten, sollte das allgemeingültig sein. Windows hat das allerdings bei FAT lange Zeit noch gemacht für das Umbenennen von Verzeichnissen. Wenn da mal zum passenden Zeitpunkt das System abgestürzt ist, hatte man schon mal zwei Verzeichnisse mit demselben Namen. Das ließ sich mWn mit den Bordmitteln nicht wieder beseitigen.

          Liebe Grüße aus dem schönen Oberharz

          Tom vom Berg

          --
           ☻_
          /▌
          / \ Nur selber lernen macht schlau
          http://bikers-lodge.com
          1. Hi,

            Übliche Locking-Mechanismen arbeiten immer so, dass es zwei Stufen der Sperre gibt:

            • shared lock: der eigene Pozess kann nur lesen, andere können lesen
                und ebenfalls shared locks setzen auf die Datei

            • exclusive lock: der eigene Prozess kann lesen und schreiben, andere können weder lesen,
                noch schreiben, noch locks setzen.

            und keinen Modus, in dem "ich selbst" schreiben und lesen darf, andere Prozesse aber immerhin lesen?
            Zumindest hatte ich unbewusst vorausgesetzt, dass es den gibt, weil ich von Windows her noch den Modus "Deny Write" beim Öffnen einer Datei kenne, der genau das leisten soll. Wenn's das bei Betriebssystemen nicht gibt ...

            Wenn ein Prozess vor hat, Daten zu verändern, muss er die exclusive Sperre bereits zum Lesen setzen, um keine Gültigkeitslücke entstehen zu lassen.

            Ja. Aber hier geht es ja ums Neu-Anlegen, nicht um Read-Modify-Write.

            Da es mWn heutzutage keine Filesysteme mehr gibt, die noch mit FCBs (File Control Blocks) arbeiten, sollte das allgemeingültig sein. Windows hat das allerdings bei FAT lange Zeit noch gemacht für das Umbenennen von Verzeichnissen.

            Stimmt, ich entsinne mich. War aber AFAIR nur damals bei alten "reinen" DOS-Versionen so, DOS 7.x hat das schon rein namensbasiert über den DOS Function Call 56h (IIRC) gemacht, der sowohl Verzeichnisse, als auch normale Dateien umbenennen und dabei sogar auf demselben Datenträger verschieben konnte.

            Wenn da mal zum passenden Zeitpunkt das System abgestürzt ist, hatte man schon mal zwei Verzeichnisse mit demselben Namen. Das ließ sich mWn mit den Bordmitteln nicht wieder beseitigen.

            Hm. Kann sein. Den Fall hatte ich nie. ;-)

            Ciao,
             Martin

            --
            Ein Snob ist ein Mensch, der sich auf ein Stachelschwein setzt, ohne eine Miene zu verziehen - nur weil ihm jemand gesagt hat, das sei ein Designersessel.
            Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
            1. Hello,

              Übliche Locking-Mechanismen arbeiten immer so, dass es zwei Stufen der Sperre gibt:

              • shared lock: der eigene Pozess kann nur lesen, andere können lesen
                  und ebenfalls shared locks setzen auf die Datei

              • exclusive lock: der eigene Prozess kann lesen und schreiben, andere können weder lesen,
                  noch schreiben, noch locks setzen.

              und keinen Modus, in dem "ich selbst" schreiben und lesen darf, andere Prozesse aber immerhin lesen?

              Dass es sowas bei irgendeinem Filesystem gibt, kann ich mir schon vorstellen.

              Aber welchen Sinn sollte es haben, dirty data lesen zu können? Man hat ja mindestens beim Mandatory Locking noch die Möglichkeit der Bereichssperre ("Satzsperre"). Da kann man dann einen oder auch mehrere Teile der Datei sperren von Byteposition bis Byteposition, auch jeweils shared oder exclusive.

              Liebe Grüße aus dem schönen Oberharz

              Tom vom Berg

              --
               ☻_
              /▌
              / \ Nur selber lernen macht schlau
              http://bikers-lodge.com
              1. Hi,

                und keinen Modus, in dem "ich selbst" schreiben und lesen darf, andere Prozesse aber immerhin lesen?
                Dass es sowas bei irgendeinem Filesystem gibt, kann ich mir schon vorstellen.
                Aber welchen Sinn sollte es haben, dirty data lesen zu können?

                ein sehr häufig auftretender Fall wären Protokoll- oder Journaldateien - also Dateien, die fortlaufend geschrieben werden, so dass es jederzeit möglich wäre, sie zumindest so weit zu lesen, wie sie schon geschrieben sind.

                Man hat ja mindestens beim Mandatory Locking noch die Möglichkeit der Bereichssperre ("Satzsperre"). Da kann man dann einen oder auch mehrere Teile der Datei sperren von Byteposition bis Byteposition, auch jeweils shared oder exclusive.

                Aber nicht immer und überall. Bei "Native Unix Filesystems" mag das noch gehen, aber schon bei einer Samba-Freigabe versagt diese Möglichkeit; beim Zugriff auf eine echte Windows-Freigabe erst recht.
                Gut, aber da ist auch nicht gewährleistet, dass andere Locks zuverlässig funktionieren ...

                Ciao,
                 Martin

                --
                Lieber Blödeleien als blöde Laien.
                Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                1. Hello,

                  und keinen Modus, in dem "ich selbst" schreiben und lesen darf, andere Prozesse aber immerhin lesen?
                  Dass es sowas bei irgendeinem Filesystem gibt, kann ich mir schon vorstellen.
                  Aber welchen Sinn sollte es haben, dirty data lesen zu können?

                  ein sehr häufig auftretender Fall wären Protokoll- oder Journaldateien - also Dateien, die fortlaufend geschrieben werden, so dass es jederzeit möglich wäre, sie zumindest so weit zu lesen, wie sie schon geschrieben sind.

                  Das geht auch schon mit dem klassischen Dateityp "text" == "append-only".

                  Da muss man gar nicht sperren zum Schreiben, weil die neue Zeile immer hinten angehängt wird und erst bei Erfolg der erlaubte Lesebereich der Datei darauf ausgedehnt wird.

                  Da war übrigens ein Fehler in der PHP-Implementation bis 5.??. Da konnte man innerhalb von Quasi-Append-Dateien (also mit dem Öffnungsmodus 'a+') auch Änderungen innerhalb des Datenbestandes der Datei durchführen. DAS ist aber nach der Definition einer "Textdatei" nicht gestattet. Der Fehler wurde dann nach längerem Qängeln auch beseitigt, und ungefähr gleichzeitig auch der neue Modus "x" eingeführt. Der ist wirklich sinnvoll. Man musste ihn vorher über eine Krücke emulieren:

                  fh(A, mode a)  -> lock (s)    um eventuell nicht vorhandene Datei öffnen/anlegen zu können
                  fh(B, mode r+) -> lock (s)    um die jetzt sicher existierende Datei zum Bearbeiten zu öffnen
                  fclose(A)      => unlock      um die zu bearbeitende Datei zur Bearbeitung frei zu geben
                  flock (B)      -> lock (x)    um zu verhindern, dass Andere gleichzeitig bearbeiten

                  Bearbeiten                    Bearbeitung durchführen

                  fclose (B)     -> unlock      habe fertig

                  Soetwas kommt immer dann zustande, wenn man mit Programmiersprachen (C / C++) arbeitet, die nicht wirklich passende API's zu den jeweiligen Betriebssystemen/Filesystemen besitzen und daher in einer höheren Schicht das Rad nochmal neu erfinden, dass es in der Betriebssystemschicht (mancher Systeme) schon (sehr viel besser gelöst) gab. Darum kann Windows (Windowsprogramme) auch nie wirklich gut und schnell werden! Da passt die Programmiersprache nicht zum Kernel.

                  Liebe Grüße aus dem schönen Oberharz

                  Tom vom Berg

                  --
                   ☻_
                  /▌
                  / \ Nur selber lernen macht schlau
                  http://bikers-lodge.com
                  1. Hi,

                    Darum kann Windows (Windowsprogramme) auch nie wirklich gut und schnell werden! Da passt die Programmiersprache nicht zum Kernel.

                    doch schon - nur dass der Kernel nicht die seit Jahrzehnten üblichen Funktionen aus der C-Standardbibliothek implementiert, sondern einen eigenen Satz an Funktionen.

                    Natürlich gibt es auch fopen(), flock(), fread() und Konsorten in den Bibliotheken der Windows-Compiler. Aber die entsprechenden Funktionen sind im Windows-Kernel nur Wrapper für CreateFile(), ReadFile() etc. mit teils völlig anderer Semantik. Microsoft empfiehlt daher, generell die Windows-spezifischen Funktionen zu verwenden.

                    Bei Funktionen zur Speicherverwaltung sieht's genauso aus: MS empfiehlt, nicht malloc() und free() zu verwenden (obwohl die natürlich auch zur Verfügung stehen), sondern deren Windows-spezifische Pendants GlobalAlloc(), GlobalLock(), GlobalFree() usw., die mehr Möglichkeiten bieten, aber dadurch auch schwieriger zu handhaben sind.

                    Dass dies dem Wunsch nach Portabilität wenigstens noch auf Quellcode-Ebene zuwiderläuft, ist logisch.

                    So long,
                     Martin

                    --
                    Dürfen Finanzbeamte eigentlich ihren Kaffee schwarz trinken? - Ich glaube ja. Aber sie dürfen ihre Tasse nicht absetzen.
                      (gehört auf SWR3)
                    Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                    1. Hello,

                      Darum kann Windows (Windowsprogramme) auch nie wirklich gut und schnell werden! Da passt die Programmiersprache nicht zum Kernel.

                      doch schon - nur dass der Kernel nicht die seit Jahrzehnten üblichen Funktionen aus der C-Standardbibliothek implementiert, sondern einen eigenen Satz an Funktionen.

                      Umgekehrt muss ein Schuh daraus werden. Das zu benutzende C-Modul muss die Fähigkeiten des Kernel abbilden, der sinnvollerweise auch heute noch oft in Assembler (nebst Hilfsmitteln) erstellt wird.

                      Liebe Grüße aus dem schönen Oberharz

                      Tom vom Berg

                      --
                       ☻_
                      /▌
                      / \ Nur selber lernen macht schlau
                      http://bikers-lodge.com
  2. Hello,

    ein Prozess (a) lädt eine große Datei und nutzt diese anschließend. Ein anderer Prozess (b) möchte diese Datei ebenso nutzen, muss aber warten, bis a diese _vollständig_ runtergeladen hat.

    Welches DBMS?
    Wie findet der Zugriff statt?
    Handelt es sich um "unbuffered Statements"?

    Wirklich "gleichzeitige" Zugriffe gibt es mMn sowieso nicht. Die Requests werden immer in Warteschlangen eingereiht und nacheinander abgehandelt. Das bedeutet aber nicht, dass der eine Prozess bereits "fertig" sein muss, bevor der andere "auch einmal" an die Reihe kommt.

    Microzugriffe sind i.d.R. atomar gekapselt, aber jede Hülle, die man mehr darum herum baut, lässt mehr Lücken zu, in denen andere Prozesse dann auch mal zum Zuge kommen können. Darum finden Lockingoperationen sinnvollerweise auch immer innerhalb des ersten Microzugriffs statt. Nachfolgende müsen sich dann daran halten.

    Zum Lesen ist "gleichzeitiges" Abfragen der Daten aber nicht schäflich. Hier ist eine eine geteilte Umgebung heute üblich.

    Liebe Grüße aus dem schönen Oberharz

    Tom vom Berg

    --
     ☻_
    /▌
    / \ Nur selber lernen macht schlau
    http://bikers-lodge.com
    1. Hi,

      ein Prozess (a) lädt eine große Datei und nutzt diese anschließend. Ein anderer Prozess (b) möchte diese Datei ebenso nutzen, muss aber warten, bis a diese _vollständig_ runtergeladen hat.
      Welches DBMS?

      wie kommst du darauf, dass es um DB-Zugriffe geht? So wie ich das lese, redet der OP von Dateioperationen, und überlegt nur, ob er File Locking eventuell über einen DB-Eintrag nachbauen kann.

      Zum Lesen ist "gleichzeitiges" Abfragen der Daten aber nicht schäflich.

      Nicht schäflich, nicht wölflich, und meist auch nicht schädlich. ;-)

      Ciao,
       Martin

      --
      Das einzige Problem beim Nichtstun: Man weiß nie, wann man damit fertig ist.
      Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
      1. Hello,

        Nicht schäflich, nicht wölflich, und meist auch nicht schädlich. ;-)

        Tja, der neue Keylogger vom NSA scheint noch fehlerhaft zu sein. Der baut immer Tippfehler ein :-P

        Liebe Grüße aus dem schönen Oberharz

        Tom vom Berg

        --
         ☻_
        /▌
        / \ Nur selber lernen macht schlau
        http://bikers-lodge.com
  3. Hallo,

    ein Prozess (a) lädt eine große Datei und nutzt diese anschließend. Ein anderer Prozess (b) möchte diese Datei ebenso nutzen, muss aber warten, bis a diese _vollständig_ runtergeladen hat.

    Warum kann Prozess a Prozess b nicht informieren? Oder warum bietet a nicht an, dass sich b als Listener registriert?

    Viele Grüße
    Siri

    1. Hallo,

      ein Prozess (a) lädt eine große Datei und nutzt diese anschließend. Ein anderer Prozess (b) möchte diese Datei ebenso nutzen, muss aber warten, bis a diese _vollständig_ runtergeladen hat.

      Warum kann Prozess a Prozess b nicht informieren? Oder warum bietet a nicht an, dass sich b als Listener registriert?

      was genau meinst du mit informieren? Die Prozesse starten von höherer Stelle abhängig, d.h. ich kann leider den Zeitpunkt des Prozess-Starts nicht selber bestimmen.

    2. Hallo,

      ein Prozess (a) lädt eine große Datei und nutzt diese anschließend. Ein anderer Prozess (b) möchte diese Datei ebenso nutzen, muss aber warten, bis a diese _vollständig_ runtergeladen hat.

      Eine Variante:

      a will datei aus netz laden
      a sucht nach flag in Form einer Datei z.B. nach /var/run - findet nichts.
      a schreibt ein flag
      a lädt herunter.
      b will datei
      b sucht und findet flag
      b schaut regelmäßig nach oder überwacht das Flag (wie auch immer)
      a ist mit laden fertig
      a löscht das flag
      b merkt das und startet durch.

      Eine etwas andere Variante:

      a will datei aus netz laden
      a sucht nach FIFO-Puffer, findet keinen
      a macht fifo Puffer auf
      a lädt herunter.
      b will datei
      b sucht und findet FIFO-Puffer
      b lauscht auf ein "fertig"
      a ist mit laden fertig und sendet "fertig"(*) zum FIFO
      b hört das und startet durch.

      (*) oder ein anderes Signal z.B. für "idle" (wichtig wenn auch Programm(e) c... gibt), "Fehler" oder "Abbruch".

      weitere Möglichkeit: Prozesskommunikation oder eben das hier

      Jörg Reinholz

      1. Hallo Jörg,

        Eine Variante:

        a will datei aus netz laden
        a sucht nach flag in Form einer Datei z.B. nach /var/run - findet nichts.
        a schreibt ein flag
        a lädt herunter.
        b will datei
        b sucht und findet flag
        b schaut regelmäßig nach oder überwacht das Flag (wie auch immer)
        a ist mit laden fertig
        a löscht das flag
        b merkt das und startet durch.

        eventuell gefällt mir die Idee mit dem Flag in Form einer Datei ganz gut. Eine Überlegung wert und es wird keine DB benötigt. Ja, gefällt mir... muss ich mal ein paar Tests machen, ob das soweit läuft.

        1. Hello,

          eventuell gefällt mir die Idee mit dem Flag in Form einer Datei ganz gut. Eine Überlegung wert und es wird keine DB benötigt. Ja, gefällt mir... muss ich mal ein paar Tests machen, ob das soweit läuft.

          Schreibst Du gerade en einem eigenen Betriebssystem/Filesystem oder warum willst Du die üblicherweise vorhandenen Mechanismen nicht nutzen?

          Liebe Grüße aus dem schönen Oberharz

          Tom vom Berg

          --
           ☻_
          /▌
          / \ Nur selber lernen macht schlau
          http://bikers-lodge.com
        2. Eine etwas andere Variante wäre die Datei zunächst nach /tmp/spezielles_verzeichnis/datei.part zu laden und nach dem erfolgreichen Download umzubenennen/zu verschieben.

          Wenn Du Einfluss auf die Quelle hast, dann kannst Du ggf. sogar eine Prüfung mit md5 einbauen. Jeder der die Datei abrufende Prozesse könnte also in  /tmp/spezielles_verzeichnis/ nach der .part-Datei suchen und dann eben warten.

          Jörg Reinholz