Gleichzeitig mit mehreren Prozessen aus einem File lesen
Hallo, ich habe ein kleine Nuss zu knacken: Ich muss aus mehreren Prozessen aus dem gleichen File lesen. Das Problem ist, dass die gleichzeitigen Zugriffe und das nicht-atomare seek+read dazu führen, dass Schrott gelesen wird. Dummerweise kann ich auch keine Funktionen aus dem Modul os verwenden, da es sich um einen Importer handelt – und os ist kein build-in Modul. damit kann ich also os.dup() ebenso wenig verwenden wie Semaphoren. Die Einzilge Lösung, die mit eingefallen ist, ist damit, das File bei jedem Lesezugriff neu zu öffnen. Gibt es einen eleganteren /und effizienteren) Weg? Hintergrund: Importer by PyInstaller: https://github.com/pyinstaller/pyinstaller/issues/1070 -- Schönen Gruß Hartmut Goebel Dipl.-Informatiker (univ), CISSP, CSSLP Information Security Management, Security Governance, Secure Software Development Goebel Consult, Landshut http://www.goebel-consult.de Blog: http://www.goebel-consult.de/blog/offi-als-alternative-zum-db-navigator Kolumne: http://www.cissp-gefluester.de/2010-01-hinterturen-allen-ortes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hartmut Goebel wrote:
Hallo,
ich habe ein kleine Nuss zu knacken:
Ich muss aus mehreren Prozessen aus dem gleichen File lesen. Das Problem ist, dass die gleichzeitigen Zugriffe und das nicht-atomare seek+read dazu führen, dass Schrott gelesen wird.
Warum verwendest Du nicht für jeden Prozess ein eigenes Filehandle? - -aj -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQGUBAEBAgAGBQJVAv1MAAoJEADcfz7u4AZjQSALv3rs1Y3lVp0PnHX1xnIuRr5o DJvR9fg0M4qRWlqnptyP5moecThYuNNi02HGI047/tJ9iepszqXZJTXXV/rhXCiA tpf0f6wik0kwjnRq71Z5BGbBVw9l8u2WmiBYyalF6ayDeRLJswpM9fAhTUkkwY06 gvqPmH0ptv7wR5o3CZUwFFNTwqhR4Tx8XF2+eyF73N97s8DRcsMGn9vVERZD7hyb zsph1nXua7hY4fkmY9n879EbiN59wptoQwk7HnMo3tLwmZrmxuoTePHbTTBtxcSm 9iM8b8hrInOIptiWt6wTw0/C1s1iBrfQehd8eL0zZW3lVPCwbkGbyO6VeX0neU++ nzPZMlsXVw01tcKIm0qeQIANb9sbI2GvvvkTC+64bhsv8jjzVrU71IbodIpegiWY WOiEFuc0pNaJi15DlJycO9t0wBLzqghuZkSXwXUaKBM9I6dGCOouH4cl7gK+AW5S ELMjzq2xbcmh+nIIyyOEsU/+RAa8Zck= =9ktf -----END PGP SIGNATURE-----
Hallo Hartmut,
wird das File während der Zugriffe verändert?
Sind es viele Files und sind sie groß?
Selbst SSDs mögen wegen des seriellen SATA Interfaces sowas nicht so gerne, bzw. sind nicht darauf ausgelegt gleichzeitig im selben Block an verschiedenen Stellen zu orgeln.
Wenn also neben dem "Schrott" der ja auch an Festplatten-Limits liegen kann, das letzte Quentchen Performance zählt, versuchs mal mit einer RAM-Disk oder einem eigenen RAM-Cache. Leider heute oft vergessen aber so sauschnell, weil DMA es direkt in die Register schieben kann. Je nach Implementierung der RAM-Disk (es gibt verschiedene Möglickeiten) kann es auch lahm werden. Persistenz (wenn Du auch schreiben musst) ist auch ein Knackpunkt.
Üblicherweise können sich nicht ohne Weiteres mehrere getrennte Pyython Prozesse eine Fileressource optimiert teilen. Ein Filehandle von mehreren Prouzessen anzusprechen geht doch glaube ich garnicht. Der Haken sind doch eher die unkoordinierten Zugriffe auf das Filesystem (disk-trashing).
Vielleicht hilfts ja.
-- Armin
One last Thing: In Python ist ein String eine Liste aus Zeichen. Wenn Du also deine Datei wie eine Datenbank oder Liste bereitstellst, kannst du den Zugriff anders organisieren. Binäre Daten und schreibende Zugriffe und die Komplexität der Dateien/Struktur sind natürlich Knackpunkte die ich nicht kenne.
Am 13.03.2015 um 16:07 schrieb Andreas Jung
Signierter PGP Teil Hartmut Goebel wrote:
Hallo,
ich habe ein kleine Nuss zu knacken:
Ich muss aus mehreren Prozessen aus dem gleichen File lesen. Das Problem ist, dass die gleichzeitigen Zugriffe und das nicht-atomare seek+read dazu führen, dass Schrott gelesen wird.
Warum verwendest Du nicht für jeden Prozess ein eigenes Filehandle?
-aj
_______________________________________________ python-de maillist - python-de@python.org https://mail.python.org/mailman/listinfo/python-de
-- Armin Carl Stroß-Radschinski | developer@acsr.de | Twitter: @syncmitter Dipl. Designer FH | project-consultant | fon +49 171 21 94699 | IRC: acsr | Skype: astrossradschinski ACSR industrialdesign | Armin Stroß-Radschinski Landgrafenstraße 32 · 53842 Troisdorf · Germany | UST. ID Nr: DE154092803 (EU VAT ID) info@acsr.de | www.acsr.de | phone +49 2241 946994 · fax +49 2241 946996
Am 13.03.2015 um 16:07 schrieb Andreas Jung:
Warum verwendest Du nicht für jeden Prozess ein eigenes Filehandle?
Naja, das gleiche Fiel immer und immer wieder zu öffnen, Buffer dafür anzulegen, etc. scheint mir ineffizient. Aber wohl die einzige Lösung. -- Schönen Gruß Hartmut Goebel Dipl.-Informatiker (univ), CISSP, CSSLP Information Security Management, Security Governance, Secure Software Development Goebel Consult, Landshut http://www.goebel-consult.de Blog: http://www.goebel-consult.de/blog/install-cyanogenmod-on-s3-mini-using-linux Kolumne: http://www.cissp-gefluester.de/2010-09-mut-zur-beschraenkung
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hartmut Goebel wrote:
Am 13.03.2015 um 16:07 schrieb Andreas Jung:
Warum verwendest Du nicht für jeden Prozess ein eigenes Filehandle?
Naja, das gleiche Fiel immer und immer wieder zu öffnen, Buffer dafür anzulegen, etc. scheint mir ineffizient. Aber wohl die einzige Lösung.
Ein Haus baut man auch zuerst von unten nach oben anstatt mit dem Dach zu beginnen. - -aj -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQGUBAEBAgAGBQJVBqscAAoJEADcfz7u4AZjnioLviZJDsBXzgJzQqyEbTUzhTxo Y7R3D3oPGgYYpx3bL7bNicazXd56KHY7wW0KUZiZreHveUcDGs6i4ouklfjvsK/i efXzZyDz7dG9JeWPfOQS+bAFqNZdfVvoP/Dep71YT/dsU6BG+toKf6Y/pY4bm+j6 5F4qVZm1gzRD7GPIzd/8ARGmDuO/zGTlK49rpQrldy6AzjSt23Acq31kDjbj3Ek8 W0ie84Eby4EoQf7t+tGQDsLKxKxc+vJTQIZNd/TTKEq4OSIbZAEKJsjgKFRSRGN+ WpkocqsP2OVleyEsn56vjKbeQTkUh9us7A7xuiNCa5P1ibsueCWF3U6k8FBQ8/Jm +XENAilGHT8uvpQBMhowvw705rBpiSn+qwmfXKjtb+fFuF1k2lt7WhVzRAU+za91 fho/tRa3yDrey7gB8voAvKIfvz8/yMfdxYoHe9Xh7lrNpUhEoVNLsurcxNch5I63 y0XaBLofYoa+TcQ7wpYl8BCT3a+hJJA= =OmIe -----END PGP SIGNATURE-----
Hartmut Goebel wrote:
Hallo,
ich habe ein kleine Nuss zu knacken:
Ich muss aus mehreren Prozessen aus dem gleichen File lesen. Das Problem ist, dass die gleichzeitigen Zugriffe und das nicht-atomare seek+read dazu führen, dass Schrott gelesen wird.
Dummerweise kann ich auch keine Funktionen aus dem Modul os verwenden, da es sich um einen Importer handelt – und os ist kein build-in Modul. damit kann ich also os.dup() ebenso wenig verwenden wie Semaphoren. Die Einzilge Lösung, die mit eingefallen ist, ist damit, das File bei jedem Lesezugriff neu zu öffnen.
Gibt es einen eleganteren /und effizienteren) Weg?
Hintergrund: Importer by PyInstaller: https://github.com/pyinstaller/pyinstaller/issues/1070
Unter Linux is os.dup eigentlich posix.dup und damit "eingebaut":
import os, sys os.dup.__module__ 'posix' os.dup.__module__ in sys.builtin_module_names True
Wie das in Windows gehandhabt wird, musst du selber recherchieren -- ich vermute es ist genauso.
Am 13.03.2015 um 16:23 schrieb Peter Otten:
Wie das in Windows gehandhabt wird, musst du selber recherchieren -- ich vermute es ist genauso.
Wie das geht, steht oben im Modul `os`. Allerdings halte ich es nicht für sinnvoll, dieses Modul nach zu implementieren. -- Schönen Gruß Hartmut Goebel Dipl.-Informatiker (univ), CISSP, CSSLP Information Security Management, Security Governance, Secure Software Development Goebel Consult, Landshut http://www.goebel-consult.de Blog: http://www.goebel-consult.de/blog/install-cyanogenmod-on-s3-mini-using-linux Kolumne: http://www.cissp-gefluester.de/2010-09-mut-zur-beschraenkung
Am 13.03.2015 um 15:38 schrieb Hartmut Goebel:
Ich muss aus mehreren Prozessen aus dem gleichen File lesen. Das Problem ist, dass die gleichzeitigen Zugriffe und das nicht-atomare seek+read dazu führen, dass Schrott gelesen wird.
Hintergrund: Importer by PyInstaller: https://github.com/pyinstaller/pyinstaller/issues/1070
Ich habe das Gefühl, dass keiner der bisherigen Antwortenden das ticket gelesen hat. Wenn ich es also richtig verstehe, verwendet der pyinstaller-Importer ein Filehandle auf das Zip-Archiv mit den zu importierenden Modulen, den er vom Parentprocess geerbt hat. Entweder muss also jeder Subprozess seinen eigen Filehandle öffnen oder du musst den Filepositionpointer durch ein Lock schützen. Chris
Am 13.03.2015 um 16:53 schrieb Christopher Arndt:
oder du musst den Filepositionpointer durch ein Lock schützen.
Da müsste natürlich ein multiprocessing.Lock sein. Das Problem ist, wie übergibst du den Lock, da pyinstaller die Kindprozesse ja nicht selbst erzeugt. Siehe zum Thema "interprocess locks" auch die interessanten Antworten hier: http://stackoverflow.com/questions/6931342/system-wide-mutex-in-python-on-li... Aber das scheint mir alles eher Herumdoktoren an den Symptomen als eine saubere Lösung zu sein. Entweder man muss damit leben, dass jeder Prozess das File selbst öffnet, oder man muss einen eigenen FileReader-Prozess implementieren, der z.B. über multiprocessing.Queues die Daten an Subprozesse weitergibt. Chris
Am 13.03.2015 um 17:15 schrieb Christopher Arndt:
Da müsste natürlich ein multiprocessing.Lock sein. Das Problem ist, wie
Das Problem ist schon, dass ich in diesem Modul nur build-in Module verwenden kann und damit steht multiprocessing.Lock() nicht zur Verfügung.
Entweder man muss damit leben, dass jeder Prozess das File selbst öffnet, oder man muss einen eigenen FileReader-Prozess implementieren, der z.B. über multiprocessing.Queues die Daten an Subprozesse weitergibt.
Für eine ausgewachsene Multi-Porozess-Anwendung wäre ein Reader-Prozess wahrscheinlich einen gute Lösung. Aber nicht für ein Tool wie PyInstaller. Wir reden ja auch von der Laufzeit-Komponente. Und da ist es m.E. ziemlicher Overkill, *alle* Anwendungen zu Multi-Prozess-Anwendugen zu machen, nur um ein paar Sonderfälle abzudecken. -- Schönen Gruß Hartmut Goebel Dipl.-Informatiker (univ), CISSP, CSSLP Information Security Management, Security Governance, Secure Software Development Goebel Consult, Landshut http://www.goebel-consult.de Blog: http://www.goebel-consult.de/blog/install-cyanogenmod-on-s3-mini-using-linux Kolumne: http://www.cissp-gefluester.de/2010-09-mut-zur-beschraenkung
Hallo Christoher, Am 13.03.2015 um 16:53 schrieb Christopher Arndt:
Ich habe das Gefühl, dass keiner der bisherigen Antwortenden das ticket gelesen hat.
Das Gefühl habe ich auch.
Wenn ich es also richtig verstehe, verwendet der pyinstaller-Importer ein Filehandle auf das Zip-Archiv mit den zu importierenden Modulen, den er vom Parentprocess geerbt hat.
Korrekt.
Entweder muss also jeder Subprozess seinen eigen Filehandle öffnen oder du musst den Filepositionpointer durch ein Lock schützen.
Schade. Ich hatte gehofft, er gibt einen "hack". Dann bleibt halt doch nur, das File jedes Mal neu zu öffnen. -- Schönen Gruß Hartmut Goebel Dipl.-Informatiker (univ), CISSP, CSSLP Information Security Management, Security Governance, Secure Software Development Goebel Consult, Landshut http://www.goebel-consult.de Blog: http://www.goebel-consult.de/blog/install-cyanogenmod-on-s3-mini-using-linux Kolumne: http://www.cissp-gefluester.de/2010-09-mut-zur-beschraenkung
participants (5)
-
Andreas Jung -
Armin Stroß-Radschinski -
Christopher Arndt -
Hartmut Goebel -
Peter Otten