Open Bug 1609712 Opened 5 years ago Updated 2 years ago

Add a test for PR_CallOnce

Categories

(NSPR :: NSPR, enhancement)

enhancement

Tracking

(Not tracked)

People

(Reporter: KaiE, Assigned: KaiE)

Details

Attachments

(1 obsolete file)

Add a test that ensures that PR_CallOnce correctly blocks secondary threads that don't win the race to call the init function.

Attached patch 1609712-v1.patch (obsolete) (deleted) — Splinter Review
Assignee: nobody → kaie
Attachment #9121335 - Flags: review?(nfroyd)

output:

output:
before call once in primary thread
entering init_once(), sleeping for a moment...
before call once in secondary thread
setting the_bool and leaving init_once()
after call once in primary thread
after call once in secondary thread
secondary thread found value of bool: 1
primary thread found value of bool: 1
number of ms main thread had to wait: 101
number of ms secondary thread had to wait: 101
PASS

Comment on attachment 9121335 [details] [diff] [review] 1609712-v1.patch Review of attachment 9121335 [details] [diff] [review]: ----------------------------------------------------------------- I'm guessing the intent of this test is to ensure that the function called by `PR_CallOnce` is only ever called once? And the underlying assumption behind the test is that the `PR_Sleep` call in the once-called function would cause things to take 100ms+ on a single thread, and therefore that only one thread should ever take 100ms to do its work? That's not a valid assumption. I think if you want to test "this function only ever gets called once", it should be done more directly, either by a) crashing if the function in question ever gets called multiple times, or b) setting a flag/value upon getting called a second time, and verifying somewhere that the value is never that value. Bonus points if you spin up multiple threads for testing that `PR_CallOnce` is robust in the face of several threads hammering on it.
Attachment #9121335 - Flags: review?(nfroyd) → review-

(In reply to Nathan Froyd [:froydnj] from comment #4)

I'm guessing the intent of this test is to ensure that the function called
by PR_CallOnce is only ever called once? And the underlying assumption
behind the test is that the PR_Sleep call in the once-called function
would cause things to take 100ms+ on a single thread, and therefore that
only one thread should ever take 100ms to do its work? That's not a valid
assumption.

No, the intention isn't to test that the function is only called once.

The intention is to ensure, that the other threads have to WAIT until after the init has completed.

This code ensures that each thread that calls PR_CallOnce is delayed at least by the amount of time the init function sleeps.

(In reply to Kai Engert (:KaiE:) from comment #5)

(In reply to Nathan Froyd [:froydnj] from comment #4)

I'm guessing the intent of this test is to ensure that the function called
by PR_CallOnce is only ever called once? And the underlying assumption
behind the test is that the PR_Sleep call in the once-called function
would cause things to take 100ms+ on a single thread, and therefore that
only one thread should ever take 100ms to do its work? That's not a valid
assumption.

No, the intention isn't to test that the function is only called once.

The intention is to ensure, that the other threads have to WAIT until after the init has completed.

Ah, I see. I saw all the code, but didn't fully process it.

Regardless, this intention is still backed by a false assumption: that all threads in the testcase have to wait in some way. The main thread can get through the PR_CallOnce before the other thread even enters the necessary lock, and so the other thread will never have to wait.

Comment on attachment 9121335 [details] [diff] [review] 1609712-v1.patch You're right. I'll come up with a better test, probably checking on both threads that a variable (or an array) has successfully be filled with expected data.
Attachment #9121335 - Attachment is obsolete: true
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: