Multithreading / TCP/IP / Signal-Handling auf 64GB SMP Kernel (2.4) (SuSE Linux 8.2)
-
Mal 'ne andere Frage: Was ist, wenn man nun einen sigwait()-Handler gemacht hat, und an die siginfo_t-Daten drankommen will (oder muss)?
Mir wuerden schon die Daten von SIGCHLD und von DNotify reichen. So weit ich sehen kann, gibt's da aber nix.
-
SIGKILL schrieb:
Mal 'ne andere Frage: Was ist, wenn man nun einen sigwait()-Handler gemacht hat, und an die siginfo_t-Daten drankommen will (oder muss)?
Mir wuerden schon die Daten von SIGCHLD und von DNotify reichen. So weit ich sehen kann, gibt's da aber nix.
Es gibt noch sigwaitinfo()
-
Ponto schrieb:
Es gibt noch sigwaitinfo()
Danke!
-
Was muss man machen, damit sigwaitinfo() funktioniert?
sigwait() geht, aber sigwaitinfo() haengt einfach nur dumm rum. (Linux 2.4)
-
SIGKILL schrieb:
Was muss man machen, damit sigwaitinfo() funktioniert?
sigwait() geht, aber sigwaitinfo() haengt einfach nur dumm rum. (Linux 2.4)
Zeig mal ein kleines Beispielprogramm, das man mal testen kann.
-
Hab kein kleines Beispielprogramm.
Es ging bloss deswegen nicht, weil ich die Signale vorher auf SIG_IGN gestellt hatte (hab das entfernt, und dann ging's, teilweise).
Es funktioniert jetzt soweit, dass Ereignisse auf File-Handles, bei denen mit F_SETOWN der Owner auf die Prozess-ID des sigwait()-Threads gesetzt ist, durchgestellt werden.
Jedoch ergibt sich das Problem, dass Signale wie SIGCHLD anscheinend ueberhaupt nicht ankommen, weil sie ja nicht fuer den sigwait()-Thread bestimmt sind. Gilt auch fuer SIGHUP etc.
Was mach ich verkehrt?
-
Ich hab's jetzt geschafft!!
Hier eine Beschreibung, fuer alle, die (mal) das gleiche Problem haben:
1. Signale, die an eine bestimmte Prozess-ID zugestellt werden koennen (wie SIGIO) kann man ueber einen sigwait()/sigwaitinfo()-Handler in einem separaten Thread behandeln. Dazu muss man alle betreffenden Signale in jedem Thread blocken (ueber pthread_sigmask()). Als Target fuer das Signal muss man die Prozess-ID des sigwait-Threads nehmen, da ja unter LinuxThreads (pthreads) auf Kernel bis 2.4 jeder Thread eine eigene Prozess-ID hat.
2. Alle anderen Signale muss man wie gehabt ueber einen Signal-Handler behandeln, der pro Signal einmal global registriert wird. Dabei muss man alle abgefangenen Signale in die sigaction()-Signalmaske eintragen. Der Signal-Handler darf keine Funktionen aufrufen, die evtl. einen Thread schlafen legen koennten. Ich habe es jetzt so gemacht, dass ich mehrere Signal-Info-Tabellen gemacht habe, die ueber den XCHG-Befehl des Prozessors (Achtung! Spezifisch fuer IA-32 Prozessorfamilie) gesperrt werden. Dabei wird nur jeweils eine Tabelle beschrieben. Anschliessend wird mit sem_post() ein Thread benachrichtigt, der auf die Semaphore wartet und die jeweilige Tabelle ausliest. Dadurch konnte das Problem ohne Wartefunktionen im Signal-Handler geloest werden.
Danke nochmal, an alle, die mir geholfen haben!
-
Zusatzinfo: die Funktionen, die man in Signal-Handlern aufrufen darf, findet man, wenn man nach "async signal safe functions" googled. sem_post() ist eh die einzige threadmäßig interessante dabei.