[LUGA] Mit freundlicher Unterstützung von:
OCG

Mail Thread Index


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[luga] Re: [RANT]: Uralt Standards (was Re: [luga] ulimit, offene filedescriptors und Vererbungslehre (länger))



On 2006-11-13 12:49:32 +0100, Bernd Petrovitsch wrote:
> On Mon, 2006-11-13 at 11:27 +0100, Peter J. Holzer wrote:
> [...]
> > Es könnte sein, dass der OpenLDAP select verwendet, das nur eine
> > hartkodierte Menge an Filedescriptoren verwalten kann (per default
> > 1024). In dem Fall hat er nicht wirklich ein Problem damit, sie zu
> 
> Aus der "1024 file descriptors should be enough for anybody" Abteilung:
> 
> Die Beschränkung ist *uralt* und kommt leider aus POSIX/SUS - da ist
> select(2) deklariert als:
> ----  snip  ----
> int select(int nfds, fd_set *restrict readfds,
>        fd_set *restrict writefds, fd_set *restrict errorfds,
>        struct timeval *restrict timeout);
> ----  snip  ----
> Dieser (eigentlich sinnlose) "fd_set" Typ kann FD_SETSIZE
> Filedescriptoren verwalten (ist idR 1024). Um das größer zu machen, muß
> man nur die Konstante raufsetzen und "nur" die (GNU-)libc neu
> kompilieren (weil FD_SETSIZE auch in den Hilfsfunktionen/macros zur
> fd_set Verwaltung - FD_CLR(), etc. - verwendet wird). [ Oder halt die
> Macros nicht verwenden und erst alles selber machen. ]
> Dem Linux-Kernel ist die Beschränkung BTW herzlich egal - der Aufrufer
> muß den größten zu beachtenden Filedescriptor sowieso mitgeben und der
> Kernel muß sich drauf verlassen können - im schlimmsten Fall killt der
> Kernel den (buggy) Prozeß mit SIGSEGV o.ä..
> 
> Etwas Zukunftsicheres hätte statt "fd_set" in der "select(2)"
> Deklaration "unsigned int *" oder "unsigned char *" genommen und die
> Verantwortung für ausreichend große Buffer auf den Programmierer
> abgeschoben (so wie bei vielen anderen Funktionen in C und/oder Unix).

Du wirst lachen, aber so war es früher (Ultrix, späte 80er-Jahre).
Dann ist offenbar irgendjemand auf die Idee gekommen, dass es doch viel
schöner wäre, wenn man das hinter einen typedef und ein paar Macros
versteckt, mit dem Ergebnis, dass ein vorher ziemlich flexibler
Systemcall ziemlich unflexibel geworden ist - zumindest wenn man ihn
"wie spezifiziert" verwendet. In Linux kann man sich seine fdsets auch
selber in passender Größe allozieren und mit Bits befüllen - dem Kernel
bzw. der glibc ist das wurscht. (Wie ich der Diskussion
http://www.openldap.org/lists/openldap-devel/200411/msg00045.html
entnehme, macht das der OpenLDAP auch so, man muss also nur den
recompilieren und nicht die glibc.


> > Wenn der Verdacht mit dem select stimmt, dann könnte es helfen,
> > OpenLDAP mit poll statt select zu rekompilieren, vorausgesetzt, der
> 
> poll(2) ist sowieso die bessere Alternative - zumal es im Linux-Kernel
> drin sowieso nur "poll" gibt (und ohne eine Referenz liefern zu können -
> und im glibc Source zu stochern - konvergiert select(2) zu einem
> User-Space-Wrapper für poll(2)).

Den System-Call gibt es sicher noch. Alte System-Calls werden in Linux
nie weggeworfen (es gibt noch einen Systemcall, den die libc2 (nicht
glibc2) benötigt hat - plus Testcases, die sicherstellen, dass der noch
funktioniert). Kann aber sein, dass die glibc den nicht mehr aufruft.

> > OpenLDAP unterstützt das. (Aber wenn OpenLDAP "genial skaliert", dann
> > sollte es, denn ein Single-Process-Server, der select verwendet,
> > skaliert nicht genial.
> 
> Naja, so sehr ich ein Fan von non-blocking I/O und non-fork()ing Servern
> bin, aber bei Multi-CPU-Maschinen könnte ein "single-threaded"
> poll()-only Server nicht so toll sein.

Ich glaube, der OpenLDAP ist multithreaded. Aber da Filedescriptoren von
allen Threads eines Prozesses geshared werden, erhöht das natürlich
nicht die Anzahl der möglichen offenen Filedescriptoren. 

	hp


-- 
   _  | Peter J. Holzer    | Ich sehe nun ein, dass Computer wenig
|_|_) | Sysadmin WSR       | geeignet sind, um sich was zu merken.
| |   | hjp@hjp.at         |
__/   | http://www.hjp.at/ |	-- Holger Lembke in dan-am

Attachment: signature.asc
Description: Digital signature



powered by LINUX the choice of a gnu generation
linux user group austria;
Suche
Suche
Letzte Änderung:
webmaster@luga.at
September 2010