6
Tengo un código en dos sistemas que ejecutan kernel 2.4.20 y kernel 2.4.38. Ambos tienen gcc 3.2.2 y glibc 2.3.2pthread_create diferencias en el núcleo de Linux 2.4.20 y 2.4.36
Bajo kernel 2.4.38, las asas pthread_t no están siendo reutilizados. En una prueba de carga pesada, la aplicación se bloquea una vez que los controladores alcanzan el 0xFFFFFFFF.
(I sospecha esto en primer lugar porque la aplicación se bloquea en las implementaciones donde utiliza un puerto de red, escáner los hilos son creados para manejar las conexiones de socket)
Este sencillo ejemplo recrea el problema:
void* ThreadProc(void* param)
{
usleep(10000);
printf(" Thread 0x%x\n", (unsigned int)pthread_self());
usleep(10000);
return NULL;
}
int main(int argc, char* argv[])
{
pthread_t sThread;
while(1)
{
pthread_create(&sThread, NULL, ThreadProc, NULL);
printf("Created 0x%x\n", (unsigned int)sThread);
pthread_join(sThread, NULL);
};
return 0;
}
Bajo 2.4.20:
Created 0x40838cc0
Thread 0x40838cc0
Created 0x40838cc0
Thread 0x40838cc0
Created 0x40838cc0
Thread 0x40838cc0
...and on and on...
Bajo 04/02/36:
Created 0x4002
Thread 0x4002
Created 0x8002
Thread 0x8002
Created 0xc002
Thread 0xc002
...keeps growing...
¿Cómo puedo obtener kernel 2.4.36 para reciclar los mangos? Desafortunadamente no puedo cambiar kernel fácilmente. Gracias!
¡Saludos al pasado! No creo que depender de tu programa en un comportamiento de kernel así sea una buena idea, debes arreglar tu programa. – PlasmaHH
@PlasmaHH: El programa está bien; 'pthread_join' debería liberar todos los recursos de hilo. El problema es que, en esa versión particular del kernel, aparentemente no es así. –
@MikeSeymour: ¿Qué te hace pensar eso? Para mí, parece que está repartiendo un identificador diferente cada vez, algo que está perfectamente bien, incluso cuando el mango anterior ha sido liberado. Al igual que a = malloc (5); libre (a); a == malloc (5); no debe ser verdad – PlasmaHH