Multithreading / TCP/IP / Signal-Handling auf 64GB SMP Kernel (2.4) (SuSE Linux 8.2)
-
Bug schrieb:
Genau! Denn Kunden sind immer höchst erfreut, wenn sie eine Software in Auftrag geben und dafür ihr System updaten müssen, damit die darauf läuft.
Denk ab und zu bitte auch mal bevor Du schreibst; darum geht es hier nicht.
Wenn ein Kunde mir den Auftrag gibt, einen sicheren Terminalserver für eine WindowsXP-Defaultinstallation ohne Service-Packs zu schreiben, dann muss ich diesem Kunden auch sagen, dass das so nicht sinnvoll wäre und er doch bitte mal die ServicePacks installieren soll; andernfalls wird das System einfach nicht wie gewünscht laufen.Power Off schrieb:
Man kann ja durchaus fuer GNU-Pakete vorschreiben, dass sie die POSIX-APIs verwenden muessen. Aber fuer proprietaere Linux-Anwendungen muss das doch nicht so sein, oder?
Bei AIX und Solaris geht das doch auch. Und AIX hat einen tollen native-Thread API, der wirklich so funktioniert, wie man es erwartet. Bei Solaris ist die native-Thread-Programmierung eher der Horror (frueher zumindest waren sogar einige Systemaufrufe und Bibliotheken bei Solaris nicht multithreadfaehig).
Der Unterschied ist aber der, dass AIX und Solaris Produkte von kommerziellen Herstellern für kommerzielle Firmen sind. Du erwartest doch wohl hoffentlich nicht, dass die Free Software Community Erweiterungen schreibt, die dem eigenen Projekt/ der Community langfristig nur schaden bzw. keine Vorteile bringen?
Also von portabler Programmierung auf UNIX-Systemen kann ueberhaupt keine Rede sein.
Portabel heisst "write once -- run everywhere". Aber selbst Java ist nicht 100%ig portabel. C und C++ ja auch nicht.
Naja, wenn Du 100%ige Portabilität nicht möglich ist (was Du ja selbst zugibst), dann nimmt man als Maßstab natürlich einfach andere Systeme.
Und wenn ich daran denke, dass eine für GNU/Linux sauber geschriebene Anwendung normalerweise mit ein paar kleineren Anpassungen ohne weiteres auch auf *BSD, MacOS X, ... läuft, dann ist das doch schon ziemlich gut.Ich behaupte hier ja nicht, dass Threading in den 2.4er Kernels toll war, aber immerhin ist das mittlerweile in der auch sonst sehr gelungenen 2.6er-Reihe behoben; was willst Du denn noch?
-
nman schrieb:
Bug schrieb:
Genau! Denn Kunden sind immer höchst erfreut, wenn sie eine Software in Auftrag geben und dafür ihr System updaten müssen, damit die darauf läuft.
Denk ab und zu bitte auch mal bevor Du schreibst; darum geht es hier nicht.
Wenn ein Kunde mir den Auftrag gibt, einen sicheren Terminalserver für eine WindowsXP-Defaultinstallation ohne Service-Packs zu schreiben, dann muss ich diesem Kunden auch sagen, dass das so nicht sinnvoll wäre und er doch bitte mal die ServicePacks installieren soll; andernfalls wird das System einfach nicht wie gewünscht laufen.Doch, darum geht es. Nicht wenige betreiben Systeme, die stabil, speziell angepasst und über einen längeren Zeitpunkt gewachsen sind. Wenn du denen erzählst daß sie's ändern sollen, damit deine Software darauf läuft, hast du einen Kunden weniger. Und du weißt selbst, ein Linux-System zu konfigurieren ist kein Spaß, kein Vergleich mit dem Aufspielen eines Service-Packs unter Windows.
-
Bug schrieb:
Doch, darum geht es. Nicht wenige betreiben Systeme, die stabil, speziell angepasst und über einen längeren Zeitpunkt gewachsen sind. Wenn du denen erzählst daß sie's ändern sollen, damit deine Software darauf läuft, hast du einen Kunden weniger.
Es gibt aber nun eben nur diese Möglichkeit, wenn man seine Kunden nicht belügen möchte. Entweder sie installieren sich einen neuen Kernel oder aber ich schreibe meine Software so, dass sie die Features, die bekanntermaßen beim verwendeten System nicht funktionieren, umgeht.
Aber wenn ich einen derartigen Auftrag angenommen habe, jammern, dass ein uraltes System etwas nicht kann wsa in der aktuellen Version ausgebügelt ist, die noch dazu frei erhältlich ist, läuft einfach nicht.
Und du weißt selbst, ein Linux-System zu konfigurieren ist kein Spaß, kein Vergleich mit dem Aufpielen eines Service-Packs unter Windows.
Ach, so ein Schwachsinn.
Für ein Update auf den 2.6er-Kernel braucht man nicht länger als 20 Minuten pro Rechner. Und danach hat man keine Probleme mit Software die mit 2.6 einfach nicht laufen möchte, wie das bei Windows-Servicepacks oftmals der Fall ist.
-
nman schrieb:
Aber wenn ich einen derartigen Auftrag angenommen habe, jammern, dass ein uraltes System etwas nicht kann wsa in der aktuellen Version ausgebügelt ist, die noch dazu frei erhältlich ist, läuft einfach nicht.
Ich jammer ja gar nicht -- ich weiss, dass die Software auf dem 2.4er Kernel laufen muss.
Update vom Kundenrechner ist ausgeschlossen, da wir ja sonst das System nicht mehr fuer SuSE Linux 8.2 anbieten koennen.
-
Für ein Update auf den 2.6er-Kernel braucht man nicht länger als 20 Minuten pro Rechner. Und danach hat man keine Probleme mit Software die mit 2.6 einfach nicht laufen möchte.
Und was ist, wenn der Kunde proprietäre Software verwendet, die nur mit genau dieser Version läuft (weil sie z.B. irgendwelche Furz-Binary-Only-Kernelmodule verwendet? Jede größere Firma verwendet haufenweise solchen Dreck, da kann man kaum was dagegen tun.
Außerdem ist das Upgraden auf NPTL so gut wie unmöglich. Man muss eigentlich ein komplettes Distributionsupdate machen, wenn die Distro das kann.
-
Ringding schrieb:
Und was ist, wenn der Kunde proprietäre Software verwendet, die nur mit genau dieser Version läuft (weil sie z.B. irgendwelche Furz-Binary-Only-Kernelmodule verwendet? Jede größere Firma verwendet haufenweise solchen Dreck, da kann man kaum was dagegen tun.
Naja, wenn solcher Dreck wichtig ist, dann hat man dafür einen Wartungsvertrag und bekommt vom Hersteller auch aktuelle Variante.
Ist aber ein guter Punkt, derartige Sachen begegnen mir in meinem Umfeld normalerweise eher nicht.Außerdem ist das Upgraden auf NPTL so gut wie unmöglich. Man muss eigentlich ein komplettes Distributionsupdate machen, wenn die Distro das kann.
Normalerweise sollte ein entsprechendes libc-Update völlig ausreichen.
Power Off schrieb:
Ich jammer ja gar nicht -- ich weiss, dass die Software auf dem 2.4er Kernel laufen muss.
Sorry, es klang einfach so. Wenn man Windows-Usern vorwirft, was für Schrott WinME ist, dann sagen die einem ja auch (völlig zu Recht), dass man Windows aber nicht an einer so alten Version messen kann.
-
derartige Sachen begegnen mir in meinem Umfeld normalerweise eher nicht.
Sei froh...
Ein Kunde von uns hat RHEL 2.1 laufen mit einem ganzen Haufen von proprietärer Compaq-Software, von der ich nicht weiß, was sie tut. Ist ebenfalls ein altes System ohne NPTL, und dieses Compaq-Zeug hat ein kräftiges memory leak, sodass es ca. einmal im Monat neu gestartet werden muss. Unsere Serveranwendung läuft aber erstaunlicherweise ziemlich stabil darauf, obwohl sie Threads verwendet.
-
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.