bugGNUstep - Bugs: bug #8085, Problem with GSLazyLock

 
 

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

bug #8085: Problem with GSLazyLock

Submitted by:  Willem Rein Oudshoorn <wim>
Submitted on:  Wed 10 Mar 2004 08:36:12 AM UTC  
 
Category: Base/FoundationSeverity: 3 - Normal
Item Group: BugStatus: None
Privacy: PublicAssigned to: Willem Rein Oudshoorn <wim>
Open/Closed: Closed

Fri 12 Mar 2004 10:06:40 PM UTC, comment #2:

This indeed should fix it. My local change, which did the same
fixed it, therefore I put this one to fixed.

Willem Rein Oudshoorn <wim>
Project MemberIn charge of this item.
Fri 12 Mar 2004 05:42:48 PM UTC, comment #1:

I think this may be due to a bug/feature in NSThread that it was not setting the flag to say that the program is multi threaded until after sending the NSWillBecomeMultiThreadedNotification. Under MacOS-X it seems that the flag is set so thaat +isMultiThreaded returns YES while handling these notifications so I changed the code in CVS to behave the same way, and I think this probably fixes the lazy lock problem.

Richard Frith-Macdonald <CaS>
Project Member
Wed 10 Mar 2004 08:36:12 AM UTC, original submission:

If you create a GSLazyLock in a "willBecomeMultiThreaded" notification
handler, the GSLazyLock is NOT initialized correctly. It will stay a GSLazyLock
and never change into a real NSLock. Reason is that the GSLazyLock
will never receive the "willBecomeMultithreaded" notification because it has
just been sent. Also the GSLazyLock does not know it should be initialized
as being Multitythreaded, because that flag has not been set yet.

You could argue that you should not use a GSLazyLock unless you know what
you are doing, however "base" uses the GSLazyLock and it is very easy
to indirecty create such a lock.
One example being, setting up an NSConnection.

Attached program demonstrates the problem.

Willem Rein Oudshoorn <wim>
Project MemberIn charge of this item.

 

Attached Files
file #1122:  MTTest.m added by wim (1KiB - application/octet-stream - Demonstrates the failure to initialize GSLazyLock correctly)

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

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 2 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Fri 12 Mar 2004 10:06:40 PM UTCwimOpen/ClosedOpen=>Closed
Wed 10 Mar 2004 08:36:12 AM UTCwimAttached File-=>Added MTTest.m, #1103

Back to the top


Powered by Savane 3.1-cleanup1