Ich muss das Verhalten von Code unter Linux untersuchen / testen, unter Umständen, dass close von Signalhandlern unterbrochen werden kann (entweder mit oder ohne SA_RESTART ). Was ist das bequemste Setup, um den close syscall für ein messbares Zeitfenster schlafen zu lassen, in dem ich versuchen könnte, den Prozess mit einem Signal zu treffen? Einige Ideen:
Aber da es ein bisschen mühsam ist, sie einzurichten, frage ich mich, ob es noch mehr Standardprodukte gibt, die ich verwenden könnte, um das gewünschte Verhalten zu erzielen.
Wenn niemand sonst eine bessere Idee hat ...
Sie könnten Ihren eigenen Zeichengerätetreiber implementieren. Beginnen Sie mit der Vorlage aus Kapitel 3 in Linux-Gerätetreibern (3. Auflage) und optimieren Sie sie so lange, bis nichts mehr blockiert ist auf nah (). (Sie können msleep oder msleep_interruptible aus Kapitel 7 verwenden, um die Blockierung durchzuführen.)
Eigentlich, wenn niemand anderes etwas anderes vorschlägt, kann ich das wahrscheinlich ziemlich schnell auspeitschen, indem ich einen vorhandenen Code, den ich habe, anpasse. Wie schnell brauchen Sie es?
[Bearbeiten]
OK, versuch das ...
Makefile:
%Vor%näher.c:
%Vor%Laden Sie das Modul mit "insmod closer.o". Wenn Sie eine einigermaßen moderne / vollständige Linux-Umgebung haben, wird udev aufwachen und automatisch / dev / closer generieren. Wenn nicht, können Sie den Geräteknoten selbst erstellen:
%Vor%(Das heißt, / sys / class / misc / closer / dev gibt den Major an: minor zu verwenden.)
Lese- und Schreibvorgänge funktionieren wie / dev / null; h., EOF bei jedem Lesen, Erfolg bei jedem Schreiben.
Ich habe überprüft, dass "cat & lt; / dev / closer" in close() für 10 Sekunden blockiert. Ich habe keinen Test erstellt, um SIGINT (oder was auch immer) zu fangen, und verifiziere, dass er tatsächlich in EINTR resultiert.
Errichtet gegen einen Kernel 2.6.32. Lass mich wissen, wie es für dich funktioniert.
Tags und Links c unit-testing linux signals