RE: [IRC-DEV] Actualizaciónobligatoria a u2.10.H.09.04

RyDeN - RedHispana.Org ryden at redhispana.org
Fri Feb 20 19:48:45 CET 2004


Uno de los motivos ha sido evitar el desperdicio de memoria, pero el
principal motivo ha sido el poder utilizar el slab allocator para reservar
memoria. Puedes buscar cómo funciona este en google pero, por lo que yo
tengo entendido, más o menos es una caché que no libera los elementos que se
utilizan con más frecuencia aumentando la velocidad del proceso. Para más
detalles, a esperar como yo a que jcea de la charla en #irc-dev ;P

Para llevarlo a cabo, se han convertido todos los campos de memoria estática
(Ej: char name[NICKLEN + 1];) a campos de memoria de tipo dinámica (Ej: char
*name). A continuación se procedía a reservar la memoria necesaria en cada
caso, mediante malloc, y a liberarla en las funciones de list.c que
liberaban la memoria de una estructura de cliente/canal/usuario. Además,
teniendo en cuenta que con esta reforma hay ocasiones en las que uno de
estos punteros puede ser nulo y provoque violaciones del segmento, procedí a
poner en cada uno de los punteros algo así como:
cptr->name ? cptr->name : "".

Al principio fue una tarea muy tediosa, sobre todo en mi segunda migración,
que fue la del ->name y el ircd está plagado del uso de este puntero. Además
con cada malloc te eternizabas ya que había que coger el tamaño exacto,
utilizar strncpy y luego poner el '\0' final, para cada vez que fuese
necesario (luego se quejan de que al principio dio muchos fallos xD).

Pero progresivamente se fueron facilitando las cosas, como por ejemplo el
tema de malloc/strncpy pasó a ser una función (SlabStringAllocDup) que lo
hacía por ti y así ya se iba compatibilizando el tema para el futuro Slab
Allocator, y el uso de la macro PunteroAcadena, para los x->ptr ? x->ptr :
"".

En cuanto a datos del ahorro de memoria, no tengo acceso a ellos. Eso se lo
tendrás que preguntar a alguien que los tenga.

Saludos.





More information about the IRC-Dev mailing list