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

Group
 
 

bug #48179: GSRegisterCurrentThread should send NSWillBecomeMultiThreadedNotification

Submitter:  Larry Campbell <lcampbel>
Submitted:  Wed 08 Jun 2016 03:52:35 PM UTC
   
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

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

Ap[plied, thanks.

Richard Frith-Macdonald <CaS>
Group 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>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

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
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by lcampbel (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-07-18 CaS StatusNone Fixed
        Open/ClosedOpen Closed
    2016-06-08 lcampbel Attached File- Added NSThread.m.patch.3, #37436

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code