bugGNUstep - Bugs: bug #48179, GSRegisterCurrentThread should...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #48179: GSRegisterCurrentThread should send NSWillBecomeMultiThreadedNotification

Submitted by:  Larry Campbell <lcampbel>
Submitted on:  Wed 08 Jun 2016 03:52:35 PM UTC  
 
Category: Base/FoundationSeverity: 3 - Normal
Item Group: BugStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: Closed

Mon 18 Jul 2016 10:50:58 AM UTC, comment #3:

Ap[plied, thanks.

Richard Frith-Macdonald <CaS>
Project Member
Wed 08 Jun 2016 07:01:56 PM UTC, comment #2:

Sorry about the formatting of that patch. I've now attached it as a file.

(file #37436)

Larry Campbell <lcampbel>
Wed 08 Jun 2016 06:59:34 PM UTC, comment #1:

Note that this should be done only if called from a non-main thread. Note also that the comment in front of the implementation of GSRegisterCurrentThread() says:

  • Sends out a <code>NSWillBecomeMultiThreadedNotification</code>
  • if the process was not already multithreaded.

which is not actually true (the patch below makes the comment true).

The following patch works for me:

      • /home/lcampbel/dev/mc7883/akamai/gnustep-base/gnustep-base-1.24.8/Source/NSThread.m 2016-06-08 13:13:07.000000000 -0400

--- ./NSThread.m 2016-06-08 14:08:17.000000000 -0400
***************

      • 591,596 ****

--- 591,598 ----
[[NSGarbageCollector defaultCollector] disableCollectorForPointer: t];
pthread_setspecific(thread_object_key, t);
GS_CONSUMED(t);
+ if (defaultThread != nil && t != defaultThread)
+ gnustep_base_thread_callback();
return YES;
}
return NO;

Larry Campbell <lcampbel>
Wed 08 Jun 2016 03:52:35 PM UTC, original submission:

Lots of gnustep base classes use GSLazyLock. GSLazyLock is a class that does nothing -- its lock and unlock methods are no-ops -- until the program becomes multithreaded, which is announced using NSWillBecomeMultiThreadedNotification, at which point GSLazyLock starts actually being a lock. The idea here is that single-threaded programs shouldn't have to pay the cost of locking and unlocking.

The problem is that this notification is sent only by -[NSThread start], so if you create threads directly (using pthread_create, say) and never use NSThread to create threads, the notification is never sent, and GSLazyLock does nothing, causing havoc.

I think the best fix would be for [NSThread _createThreadForCurrentPthread] to call gnustep_base_thread_callback().

Larry Campbell <lcampbel>

 

Attached Files
file #37436:  NSThread.m.patch.3 added by lcampbel (517B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by CaS (Posted a comment)
  • -unavailable- added by lcampbel (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 18 Jul 2016 10:50:58 AM UTCCaSStatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Wed 08 Jun 2016 07:01:56 PM UTClcampbelAttached File-=>Added NSThread.m.patch.3, #37436

    Back to the top


    Powered by Savane 3.1-cleanup1