Hallo
jetzt habe ich ja mal ne weile ohne Hilfe durchgehalten und hoffe es geht so weiter...
Also mein Problem:
Ich schreibe einen File Browser in pygtk, mittels "file"(das linux programm) lese ich heraus was es für eine Datei ist und entscheide dann was für ein icon hingehört (oder ist das schon wieder zu gut gemeint?, reicht nur die Dateiendung?)
wiel das ja recht lange geht starte ich für alle Dateien einen Thread (modul thread), dabei erhalte ich recht oft ein "Segmentation fault" kann es an den anzahl der Thread liegen? Ich die beenden sich ja nach ablauf selber, wenn aber viele Bilder in einem Ordner sind von denen ich alle die Vorschau erstelle laufen ja doch etliche nebeneinander (so vieleicht 20 oder mehr).
kann es an der Anzahl liegen?
bevor ich Threads eingesetzt habe ging es normalerweise ohne probleme.
Gruß
Andyh
Segmentation fault wo ich nur hinschauhe
Meinen Dickschädel schon bemerkt?
Ich bin jetzt FACHARBEITER (Zerspanungsmechaniker)!!!
[code]import sys
if sys.platform == "win32":
print "this program only runs on operating systems!!!"
sys.TotalError()[/code]
Ich bin jetzt FACHARBEITER (Zerspanungsmechaniker)!!!
[code]import sys
if sys.platform == "win32":
print "this program only runs on operating systems!!!"
sys.TotalError()[/code]
Das liegt nicht am Threadlimit, dieses würde keinen Segfault generieren (Fehlerfreiheit der zugrundeliegenden Bibliotheken vorausgesetzt 
), sondern eine Exception werfen.
Kann es sein, daß Du irgendwelche globalen Datenstrukturen von den Threads aus manipulierst, z.B. Elemente der Gui, ohne ausreichendes Locking?
), sondern eine Exception werfen.Kann es sein, daß Du irgendwelche globalen Datenstrukturen von den Threads aus manipulierst, z.B. Elemente der Gui, ohne ausreichendes Locking?
Hallo
Danke für deine Antwort!
hmm das ist jetzt aber doof.
Das Locking habe ich wie im lehrbuch gemacht.
Ich werde mal nochmal denn betroffenen code anschauhen, das dauert aber
Gruß
Andyh
Danke für deine Antwort!
hmm das ist jetzt aber doof.
Das Locking habe ich wie im lehrbuch gemacht.
Ich werde mal nochmal denn betroffenen code anschauhen, das dauert aber
Gruß
Andyh
Meinen Dickschädel schon bemerkt?
Ich bin jetzt FACHARBEITER (Zerspanungsmechaniker)!!!
[code]import sys
if sys.platform == "win32":
print "this program only runs on operating systems!!!"
sys.TotalError()[/code]
Ich bin jetzt FACHARBEITER (Zerspanungsmechaniker)!!!
[code]import sys
if sys.platform == "win32":
print "this program only runs on operating systems!!!"
sys.TotalError()[/code]
Kannst Du mal den Threadcode hier posten? Dürfte ja nicht soviel sein.
Nochwas: Für jede Datei einen neuen Thread scheint mir etwas übertrieben. Abseits des Segfaults erreichst Du so tatsächlich schnell das Threadlimit. Besser scheint mir da ein Threadpool geeignet, wobei sich jeder Thread die Arbeit aus einer Queue holt und nach Bestimmung des Dateityps diesen in eine Queue zurückschreibt und die nächste Datei abarbeitet bis keine Arbeit mehr anliegt.
Btw, dauert das "file" wirklich so lange, daß Du überhaupt auf Threads zurückgreifen mußt? Alternativ könntest Du auch ein Default-Icon anzeigen, während der Browser das richtige Icon rausfischt (so machts der Konqueror unter KDE 3.5). Dafür würde ein Thread reichen. Um die Gui responsiv zu halten, ginge das sogar getimert, allerdings ist die Iconauflösung dann fühlbar.
Wie rufst Du "file" eigentlich auf? subprocess.Popen? Da gibts nämlich Probleme mit Threads (der Popen-Konstruktor enthält einen callback zu ALLEN offenen Popen-Objekten und pollt diese an, daher womöglich das Segfault). Für libmagic gibts auch Python-bindings (Library hinter file). Allerdings erhältst Du hier nur einen Geschwindigkeitvorteil, wenn sie auch den GIL lösen während der "file"-Aktion. Keine Ahnung, wie es um diese Bindings da bestellt ist. (Wenn überhaupt, da das Filesystem ja eine beschränkte Ressource ist und "file" alle Dateien anfassen muß.)
Zu Deiner Frage, ob die Dateiendung unter Linux reicht oder file nötig ist:
Streng genommen weder noch. Dateiendungen sind unter Posix nicht für die Typenerkennung vorgesehen. Daher kannst Du dranhängen, was Du willst. Die Dateiendungssache hat sich aber auch hier etabliert, vorallem für Dateitypen mit Überschneidungen (meist Textdateien). Hier gibt Dir in der Regel nur noch die Endung den richtigen Hinweis auf den Dokumenttypen bzw. Programmzugehörigkeit. Wobei neuere libmagic-Versionen auch das berücksichtigen. So sind Openofficetextdateien .odt für ältere libmagics zip-Dateien während neuere das richtig als Openoffice-Dokument identifizieren.
Nochwas: Für jede Datei einen neuen Thread scheint mir etwas übertrieben. Abseits des Segfaults erreichst Du so tatsächlich schnell das Threadlimit. Besser scheint mir da ein Threadpool geeignet, wobei sich jeder Thread die Arbeit aus einer Queue holt und nach Bestimmung des Dateityps diesen in eine Queue zurückschreibt und die nächste Datei abarbeitet bis keine Arbeit mehr anliegt.
Btw, dauert das "file" wirklich so lange, daß Du überhaupt auf Threads zurückgreifen mußt? Alternativ könntest Du auch ein Default-Icon anzeigen, während der Browser das richtige Icon rausfischt (so machts der Konqueror unter KDE 3.5). Dafür würde ein Thread reichen. Um die Gui responsiv zu halten, ginge das sogar getimert, allerdings ist die Iconauflösung dann fühlbar
.Wie rufst Du "file" eigentlich auf? subprocess.Popen? Da gibts nämlich Probleme mit Threads (der Popen-Konstruktor enthält einen callback zu ALLEN offenen Popen-Objekten und pollt diese an, daher womöglich das Segfault). Für libmagic gibts auch Python-bindings (Library hinter file). Allerdings erhältst Du hier nur einen Geschwindigkeitvorteil, wenn sie auch den GIL lösen während der "file"-Aktion. Keine Ahnung, wie es um diese Bindings da bestellt ist. (Wenn überhaupt, da das Filesystem ja eine beschränkte Ressource ist und "file" alle Dateien anfassen muß.)
Zu Deiner Frage, ob die Dateiendung unter Linux reicht oder file nötig ist:
Streng genommen weder noch. Dateiendungen sind unter Posix nicht für die Typenerkennung vorgesehen. Daher kannst Du dranhängen, was Du willst. Die Dateiendungssache hat sich aber auch hier etabliert, vorallem für Dateitypen mit Überschneidungen (meist Textdateien). Hier gibt Dir in der Regel nur noch die Endung den richtigen Hinweis auf den Dokumenttypen bzw. Programmzugehörigkeit. Wobei neuere libmagic-Versionen auch das berücksichtigen. So sind Openofficetextdateien .odt für ältere libmagics zip-Dateien während neuere das richtig als Openoffice-Dokument identifizieren.
Hallo
Cool während du das :
Jetzt sind die Segfault weg, es lag tatsächlich an den subprocess.Popen()
Darauf währe ich ja nie gekommen, DANKE
Ich habe jetzt ja wie du schon geschrieben hast nur noch ein Thread mit subprocess.Popen(), da dürfte es jetzt nicht mehr brauchen.
Gruß
Andyh
Cool während du das :
geschrieben hast habe ich es schon programmiert.Btw, dauert das "file" wirklich so lange, daß Du überhaupt auf Threads zurückgreifen mußt? Alternativ könntest Du auch ein Default-Icon anzeigen, während der Browser das richtige Icon rausfischt (so machts der Konqueror unter KDE 3.5). Dafür würde ein Thread reichen. Um die Gui responsiv zu halten, ginge das sogar getimert, allerdings ist die Iconauflösung dann fühlbar Wink.
Jetzt sind die Segfault weg, es lag tatsächlich an den subprocess.Popen()
Darauf währe ich ja nie gekommen, DANKE
Ich habe jetzt ja wie du schon geschrieben hast nur noch ein Thread mit subprocess.Popen(), da dürfte es jetzt nicht mehr brauchen.
Gruß
Andyh
Meinen Dickschädel schon bemerkt?
Ich bin jetzt FACHARBEITER (Zerspanungsmechaniker)!!!
[code]import sys
if sys.platform == "win32":
print "this program only runs on operating systems!!!"
sys.TotalError()[/code]
Ich bin jetzt FACHARBEITER (Zerspanungsmechaniker)!!!
[code]import sys
if sys.platform == "win32":
print "this program only runs on operating systems!!!"
sys.TotalError()[/code]
Nachtrag:
"file" versteht sich auch mit Dateilisten. Damit bräuchtest Du den Subprozess nur einmal starten. Mit -b lassen sich die Dateinamen unterdrücken und mit -i erhältst Du den mimetype.
Z.B. so:
Übergibst Du file die Dir eh schon bekannte Dateiliste, korrespondiert der filetypes_from_readlines[x] mit filelist[x].
"file" versteht sich auch mit Dateilisten. Damit bräuchtest Du den Subprozess nur einmal starten. Mit -b lassen sich die Dateinamen unterdrücken und mit -i erhältst Du den mimetype.
Z.B. so:
Code: Alles auswählen
#>file -i -b ./*
application/pdf
text/plain charset=utf-8
image/gif
application/x-not-regular-file
application/x-not-regular-file
text/plain charset=us-ascii
application/pdf
application/x-not-regular-file
text/plain charset=us-ascii
application/zip
image/png