bug in NSException.m: _NSAddHandler (was: NSThread.m: GSCurrentThread() doesn't create new instance)

[Michael Scheibler]

Well it's some time ago, but now I have this problem with unregistered
threads again. Actually it seems to be a bug in GNUstep's exception
handling, which uses _NSAddHandler and _NSRemoveHandler:

void
_NSAddHandler (NSHandler* handler)
{
  NSThread *thread;

  thread = GSCurrentThread();
  // didn't call GSRegisterCurrentThread()
  // -> thread is NULL
  handler->next = thread->_exception_handler;
  thread->_exception_handler = handler;
}

void
_NSRemoveHandler (NSHandler* handler)
{
  NSThread *thread;

  thread = GSCurrentThread();
  // still didn't call GSRegisterCurrentThread()
  // -> thread most likely will be NULL, too
  thread->_exception_handler = thread->_exception_handler->next;
}


Michael Scheibler



To: "Michael Scheibler" <michael.scheibler@onevision.de>
Sent: Thursday, April 12, 2001 1:56 PM


> Michael Scheibler wrote:
> >
> > I am just trying to replace gnustep-base 0.6.5 with 1.0.0 and found out
that
> > the implementation of GSCurrentThread() has been changed so that it
doesn't
> > create a new NSThread instance if none exists for the current thread.
> > We are using GNUstep together with Java (not JIGS but our own bridge)
and
> > therefore have different Java threads which makes it necessary that
> > GSCurrentThread() works safe.
> > Why has this been changed? Would it be possible to reimplement this
> > functionality?
>
>
> I'm guessing that you actually need to use GSRegisterCurrentThread() and
> GSUnregisterCurrentThread().  These functions have been added to provide
> a clean way for the threading systems of other languages (such as Java)
> to interact with NSThreads.  The GSCurrentThread() function is intended
> purely to return the current thread ... not to be used for thread
> creation.
>