-
Notifications
You must be signed in to change notification settings - Fork 6.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tests: posix: common: do not overspecify pthread_attr_t #67094
tests: posix: common: do not overspecify pthread_attr_t #67094
Conversation
1d18cf9
to
aed0301
Compare
Much of tests/posix/common still overspecifies pthread_attr_t options. Default thread attributes are perfectly fine for the vast majority of spawned threads in this testsuite, so simply use a NULL pthread_attr_t* argument. This fixes piles of bugs because we have not properly used pthread_attr_destroy() appropriately. Signed-off-by: Christopher Friedt <[email protected]>
Much of tests/posix/common still overspecifies pthread_attr_t options. Default thread attributes are perfectly fine for the vast majority of spawned threads in this testsuite, so simply use a NULL pthread_attr_t* argument. This fixes piles of bugs because we have not properly used pthread_attr_destroy() appropriately. Signed-off-by: Christopher Friedt <[email protected]>
Much of tests/posix/common still overspecifies pthread_attr_t options. Default thread attributes are perfectly fine for the vast majority of spawned threads in this testsuite, so simply use a NULL pthread_attr_t* argument. This fixes piles of bugs because we have not properly used pthread_attr_destroy() appropriately. Signed-off-by: Christopher Friedt <[email protected]>
Much of tests/posix/common still overspecifies pthread_attr_t options. Default thread attributes are perfectly fine for the vast majority of spawned threads in this testsuite, so simply use a NULL pthread_attr_t* argument. This fixes piles of bugs because we have not properly used pthread_attr_destroy() appropriately. This is only a partial cleanup for pthread.c Signed-off-by: Christopher Friedt <[email protected]>
Much of tests/posix/common still overspecifies pthread_attr_t options. Default thread attributes are perfectly fine for the vast majority of spawned threads in this testsuite, so simply use a NULL pthread_attr_t* argument. This fixes piles of bugs because we have not properly used pthread_attr_destroy() appropriately. Signed-off-by: Christopher Friedt <[email protected]>
aed0301
to
c629ef3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good cleanup in general, just one suggestion -- I'd leave the active code outside the zassert calls so that they just verify values and don't have the action include. e.g.
instead of
zassert_ok(pthread_setspecific(key, value), "pthread_setspecific failed");
use
ret = pthread_setspecific(key, value);
zassert_ok(ret, "pthread_setspecific failed");
I do see the usefulness in keeping temporary variables around but also feel it's a matter of personal preference / utility. Definitely agree if the value is read / written more than once in a test. Worthwhile suggestion in any case. |
Much of tests/posix/common still overspecifies pthread_attr_t options. Default thread attributes are perfectly fine for the vast majority of spawned threads in this testsuite, so simply use a NULL pthread_attr_t* argument. This fixes piles of bugs because we have not properly used pthread_attr_destroy() appropriately. Signed-off-by: Christopher Friedt <[email protected]>
|
I was thinking more as a way to ensure the 'real' code was visible by separating it from the 'test framework' bits. Kinda like making sure that your 'assert' statements never have side-effects. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
It would be beneficial to do that if this were an But this is an integration test intentionally written for the ZTest framework. So there is no need to be cautious that zasserts would evaluate to nothing. Functions also definitely do evaluate correctly from within zassert statements. |
@keith-packard - could you please re-approve? |
Originally, Zephyr only supported statically defined thread stacks.
That is actually the exception in terms of how pthreads are typically spawned. The norm is simply passing a
NULL
pthread_attr_t *
and using a stack allocated by the implementation.For the vast majority of test cases involving typically trivial workloads, there is zero need to manually specify stack sizes, priorities, scheduling parameters, etc, unless actually testing that functionality, and therefore no reason to specify
pthread_attr_t
, sinceNULL
will simply pull from the pool of preallocated thread stacks.This highlights an aspect of the testsuite that needs to be fixed as part of #67091
Moreover, virtually everywhere we have used
pthread_attr_init()
, there is insufficient care taken to callpthread_attr_destroy()
in the various failure cases. That complexity is mitigated by using automatic thread stacks, as the POSIX API manages the thread stack for us. The significance of this is quite obvious once those functions are modified to manage thread stacks (rather than funnelling it all intopthread_create()
), because not callingpthread_attr_destroy()
translates to memory leaks.By passing in a
NULL
pthread_attr_t *
topthread_create()
we can avoid retrofitting dozens ofpthread_attr_destroy()
instances throughout the testsuite while simultaneously making the tests more concise and easier to maintain.Additionally, make tests more concise / accurate by switching to e.g.
zassert_ok()
, rather thanzassert_false()
,zassert_not_null()
rather thanzassert_equal((int)x, (int)y)
, etc.This PR fixes a difficult-to-enumerate number of bugs in the POSIX testsuite.
(Partially)
Fixes #67178