I have some code on two systems running kernel 2.4.20
and kernel 2.4.38
.
They both have gcc 3.2.2
and glibc 2.3.2
Under kernel 2.4.38
, the pthread_t handles aren't being reused. Under a heavy load test the application crashes once the handles reach 0xFFFFFFFF
.
( I suspected this in the first place because the app crashes in deployments where IT uses a network port scanner- the threads are created for handling socket connections )
This simple example recreates the problem:
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;
}
Under 2.4.20:
Created 0x40838cc0
Thread 0x40838cc0
Created 0x40838cc0
Thread 0x40838cc0
Created 0x40838cc0
Thread 0x40838cc0
...and on and on...
Under 2.4.36:
Created 0x4002
Thread 0x4002
Created 0x8002
Thread 0x8002
Created 0xc002
Thread 0xc002
...keeps growing...
How can I get kernel 2.4.36
to recycle handles? Unfortunately I can't change kernel easily.
Thanks!
The biggest change to LKMs between Linux 2.4 and Linux 2.6 is an internal one: LKMs get loaded much differently. Most people won't see any difference except that the suffix on a file containing an LKM has changed, because they use high level tools to manage the LKMs and the interface to those tools hasn't changed.
PARAMETERS. Is the location where the ID of the newly created thread should be stored, or NULL if the thread ID is not required. Is the thread attribute object specifying the attributes for the thread that is being created. If attr is NULL, the thread is created with default attributes.
The maximum number of threads is dependent upon the size of the private area below 16M. pthread_create() inspects this address space before creating a new thread. A realistic limit is 200 to 400 threads.
The pthread_create() function is used to create a new thread, with attributes specified by attr, within a process. If attr is NULL, the default attributes are used. If the attributes specified by attr are modified later, the thread's attributes are not affected.
If your observations are correct, only two possible solutions exist.
Either
Option 2 is something you can do even if the kernel is misbehaving. You can hold a pool of threads that remain in a sleeping state when not being used. Thread pools are a widely known software engineering pattern (see http://en.wikipedia.org/wiki/Thread_pool_pattern). This is probably the better solution for you.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With