[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
libobjc threads leak?
From: |
Larry Campbell |
Subject: |
libobjc threads leak? |
Date: |
Tue, 8 Feb 2005 22:34:36 -0500 |
I just switched from gcc 2.95.x, where the GNUstep dox say I must use
gnustep-objc, to gcc 3.3 where they say the built-in libobjc works
fine. But it doesn't. It leaks threads, so eventually your program
crashes in objc_detach_thread. The reason is that in gcc's libobjc,
threads are created joinable, so when they exit they hang around
forever waiting to be joined.
In gthr-posix.h:
if (!(pthread_create (&new_thread_handle, NULL, (void *) func, arg)))
the second argument to pthread_create is NULL, which means default
attributes, which on linux 2.4 I believe means the threads are
joinable, not detached. Now it looks like someone thought about this a
bit because in the same gthr-posix.h there is a variable called
_objc_thread_attribs initialized thusly:
/* The normal default detach state for threads is
* PTHREAD_CREATE_JOINABLE which causes threads to not die
* when you think they should. */
if (pthread_attr_init (&_objc_thread_attribs) == 0
&& pthread_attr_setdetachstate (&_objc_thread_attribs,
PTHREAD_CREATE_DETACHED)
== 0)
return 0;
but _objc_thread_attribs, which you would think would be used as
pthread_create's second argument, is in fact never used at all!
Note that the thr-posix.c in gnustep-objc has nearly identical code
that works -- it remembers to pass the _objc_thread_attribs in:
if (!(pthread_create(&new_thread_handle, &_objc_thread_attribs,
(void *)func, arg)))
So, am I missing something here, or is gcc's built-in libobjc totally
useless for multithreaded programs?
- libobjc threads leak?,
Larry Campbell <=