[GELÖST] HttpUtils_NonblockingGet und Fileupload

Begonnen von CoolTux, 15 Juni 2020, 11:04:24

Vorheriges Thema - Nächstes Thema

CoolTux

Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

mumpitzstuff


Christoph Morrison

Zitat von: rudolfkoenig am 15 Juni 2020, 18:10:24
- die Daten kann man auch ohne explizite Schleife mit "my $data = join("", <$in>);" reinlesen. Diese Variante hat aber den doppelten Speicherbedarf gegenueber deine.

Oder

{
    local $/ = undef;           # $/ is $INPUT_RECORD_SEPARATOR or $RS in English
    my $data = <FILEHANDLE>;
}


Oder:

use File::Slurp;        #   auto-imports read_file, core-module
my $file_content = read_file($file);


rudolfkoenig

@mumpitzstuff: Ich gehe davon aus, dass hier ein Missverstaendnis vorliegt.
In diesem Thread wird thematisiert, dass das Hochladen der Daten wegen begrenzten Netzwerk FHEM blockiert.
Das Einlesen der Daten aus einer Datei blockiert normalerweise FHEM nicht.
Die verlinkte Dokumentation ist fuer blockierende Dateizugriffe gedacht, was (wie im Dokument erwaehnt) eher fuer sowas wie serielle Schnittstellen relevant sind.

FHEM arbeitet fuer serielle Leitungen mit einem anderen Modell: ein(!) sysread darf nur erfolgen, wenn das globale select sein ok gibt (und ReadFn des Moduls aufruft).
Fuer write mit "select-Genehmigung" ist das Verfahren in FHEM verstecker/seltener genutzt (Stichwort: directWriteFn), weil write in der Praxis selten das Blockieren des Prozesses bewirkt.

mumpitzstuff

Ich hatte nur kurz reingesehen an dem Punkt wo cooltux Bedenken hatte, dass das lesen/schreiben der Datei zu lange blockieren würde und wollte nur darauf hinweisen, das man auch anscheinend auch non blocking in eine Datei lesen/schreiben kann. Den restlichen Kontext hatte ich dabei nicht im Blick.