[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ssh und maximale Laufzeit definieren
[Thread Prev] | [Thread Next]
- Subject: Re: ssh und maximale Laufzeit definieren
- From: Alexander Holler <holler@xxxxxxxxxxxxx>
- Date: Tue, 28 Oct 2008 20:22:58 +0100
- To: uugrn@xxxxxxxxxxxxxxx
Michael Lestinsky wrote: > Hallo Alex, > > (wir haben das zwar im IRC bereits halbwegs angesprochen, aber ich moechte > nicht, dass im Mailarchiv Unsinn unwidersprochen stehen bleibt. ;-)) Danke, gleichfalls. ;) > > > void sighandler (int sig) { > > ... > > > } > > > > > > int main () { > > ... > > > signal(SIGALRM, sighandler); // Signalhandler registrieren > > ... > > > return 0; > > > } > > Dein Signal-Handler "frisst" das Signal, damit wait es mitbekommt, > > musst du den default-handler (bzw. den vorherigen) im signalhandler > > aufrufen. Den bekommst du von signal zurueckgeliefert. > > Das ist nicht der Grund, warum das wait() auf ein Signal hin nicht > abbricht. Es waere nach meinem Gefuehl auch irgendwie ein Bruch der Trennung > zwischen Kernelcode und Usercode, wenn ein Signalhandler solche Seiten- > effekte auf andere Systemcalls haette. > Ich verstehe es bis heute noch nicht so recht und habe auch im > FBSD Kernelcode herumgestochert. Was da eigentlich passiert ist mir > nachwievor schleierhaft. Beim Aufruf von wait() liegt noch die (g)libc zwischen Userland und Kernel. Desweiteren reden wir beide bestimmt von verschiedenen implementierten wait()-Funktionen. In meiner Linux-manpage zu wait steht noch eine ganze Menge Zeug bzgl. den Unterschieden zwischen Posix, BSD und Linux-Implementationen sowie Verweise auf Funktionen wie sigaction(). Dort gibt es auch wieder jede Menge Anmerkungen gleicher Art. > Man kann sich natuerlich darauf einigen, dass Signale Teufelszeug sind. ;-) Gerne. ;) Fuer sowas sind geeignete Libraries die stabile Abstraktionen mit aehnlichen Funktionalitaeten bereitstellen eigentlich das Mittel der Wahl. Das angesprochene Problem haette ich z.B. mit nem Thread geloest, weil mir nicht sonderlich viel daran liegt, die diversen Unterschiede alter Unix-Calls auf verschiedenen Systemen kennenzulernen (muessen). Das ist zwar interessant, aber doch sehr muehsam, da man sich doch nicht einfach alles erlesen kann. Die Implementationen aendern sich teilweise ja auch mit verschiedenen BS oder libc-Versionen. Gruss, Alexander -- http://mailman.uugrn.org/mailman/listinfo/uugrn Wiki: http://wiki.uugrn.org/wiki/UUGRN:Mailingliste Archiv: http://lists.uugrn.org/