Hallo, ich bin neu und benutze dieses Forum nicht oft.
Ich habe ein Problem mit den CRS-tests besonders mir dem def build_crs_matrix(n, row_callback) Teil.
Die Test geben mir hier immer diesen Fehler raus: "Aufgabe 2a: CRS-Matrix erzeugen (1 Punkt)
Beim Laden des Moduls crs ist ein Fehler vom Typ ‚Can’t pickle <function
at 0x0000021A20B2CB80>: attribute lookup on main failed‘
aufgetreten.
Diese Teilaufgabe enthält Fehler!"
Ich bin zwar nicht der größte Python experte, aber glaube das es sich um einen Fehler in den Tests handelt, da dort Lambda mit Multithreads verbunden werden und das nicht besonders gut mit einander harmoniert und es bei der Kommunikation 2er Threads Probleme gibt.
Ich brauch noch einen Punkt aus der Aufgabe und da der Rest auch darauf aufbaut bin ich jetzt etwas aufgeschmissen und hoffe, das es schnell gelöst wird.
Edit: Rechtschreibfehler
Ich habe den selben Fehler. Ich hab mich dann einfach dazu entschieden, im CIP zu programmieren.
Welchen Code Editior benutzt du im Cip bzw. geht das auch Remote ?
Bzw. der Aufwand des Programmes sollte doch nicht so großsein, das Parallele Programmierung hier nötig ist.
Hallo zusammen,
dieser Fehler tritt soweit ich das beurteilen kann primär auf Windows auf (und potenziell auf MacOS, aber das hab ich bisher noch nicht gesehen). Auf Linux, insbesondere auf den CIP-Rechnern, gibt es keine Probleme, daher kann ich euch grade nur empfehlen, dort zu arbeiten.
Die Ursache ist diese: Wir nutzen Python-multiprocessing, um die Testfälle parallel in mehreren Prozessen auszuführen (mehrere Threads gehen in Python nicht, wegen des Global Interpreter Lock kann Python kein echtes Multithreading). Auf Linux gibt’s keine Probleme, da Linux neue Prozesse mit dem Fork-Mechanismus erzeugt und daher alle Daten im Kindprozess bereits vorliegen. Windows, und mit entsprechenden Einstellungen auch MacOS, erzeugen neue Prozesse per spawn. Daher müssen alle Daten serialisiert und an den neuen Prozess gesendet werden. Das geschieht per pickle - aber Lambdas kann man nicht picklen. Case closed.
Das ist uns leider erst sehr spät aufgefallen. Entschuldigt bitte die Unannehmlichkeiten.
Liebe Grüße,
Frederik
Broken on Windows == works as intended…
Wie zur hölle überlebt Windows ohne ein Fork???
Ugh, hab gerade in die Cygwin-Doku geschaut, wie der Posix-Compat-Layer das macht, und kriege sofort starke Kopfschmerzen:
Cygwin fork() essentially works like a non-copy on write version of fork() (like old Unix versions used to do). Because of this it can be a little slow. In most cases, you are better off using the spawn family of calls if possible.
Here’s how it works:
Parent initializes a space in the Cygwin process table for child. Parent creates child suspended using Windows CreateProcess call, giving the same path it was invoked with itself. Parent calls setjmp to save its own context and then sets a pointer to this in the Cygwin shared memory area (shared among all Cygwin tasks). Parent fills in the child’s .data and .bss subsections by copying from its own address space into the suspended child’s address space. Parent then starts the child. Parent waits on mutex for child to get to safe point. Child starts and discovers if has been forked and then longjumps using the saved jump buffer. Child sets mutex parent is waiting on and then blocks on another mutex waiting for parent to fill in its stack and heap. Parent notices child is in safe area, copies stack and heap from itself into child, releases the mutex the child is waiting on and returns from the fork call. Child wakes from blocking on mutex, recreates any mmapped areas passed to it via shared area and then returns from fork itself.