[Top][All Lists]

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

Gnustep-base thread creation bug.

From: Chris Ball
Subject: Gnustep-base thread creation bug.
Date: Fri, 27 Apr 2007 14:56:02 -0700

Right now there appears to be a slightly subtle bug in thr-pthread.m.
Specifically the threads created here are created as joinable threads, this is
bad because joinable threads have to be joined before their memory is
released.  What we really want here are detached threads that just go away when
they are done executing.  

This is trivial to test, create a program that spawns threads that do nothing
but exit and watch as the memory usage explodes as the thread count grows (I
manage around 300 threads before a cryptic message that actually means ENOMEM
turns up).

There are two different easy methods to fix this problem:
1.) change __objc_init_thread_system(void) thusly:

/* Initialize the threads subsystem. */
  /* Initialize the thread storage key */
  if (pthread_key_create(&_objc_thread_storage, NULL) == 0)
       * 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)
          if (pthread_attr_setdetachstate(&_objc_thread_attribs,
                                          PTHREAD_CREATE_DETACHED) == 0)
            return 0;

  return -1;

This makes all the threads default to the detached state.  This is incidentally
the code from thr-posix.c in the GCC source that the other code was doubtlessly
cribbed from and the backend code that old versions of gnustep just used

2.) modify __objc_thread_detach(blah blah blah) to have a call to

This is less desirable in my opinion because it is a bit more work at runtime
for no good reason and adds the question of what to do if pthread_detach
doesn't work.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]