While here, rephrase unclear passages, add references and fix the
example's style.
MFC after: 2 weeks
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 55322 Build 52211: arc lint + arc unit
Event Timeline
| share/man/man3/pthread_attr_get_np.3 | ||
|---|---|---|
| 51 | You're right, and I have been knowing it first hand since I've analyzed substantially this area and changed the priority-related attributes (not published yet). I was mostly concentrating on getting the initial changes right before coming to that part. But OK, let's do it while here. | |
| 101 | In fact, we guarantee that a not explicitly initialized, but implicitly initialized to NULL, attributes object will cause EINVAL. Problem is, there is no implicit initialization for local variables. I'll fix the text. | |
Comment Actions
Fix the description of which data is returned. Add the guarantee that the passed object is left unmodified in case the function reports failure (depends on D43329). Mention ENOMEM as a possible return value.
| share/man/man3/pthread_attr_get_np.3 | ||
|---|---|---|
| 46 | It's not current, since the value computed and used internally is never reflected back into the attributes object. We would need to modify cpu_set_upcall() to change that fact, and it's not in my plans. The fact that the stack top can't change after the thread start, besides being obvious, is completely independent. | |
| 57–71 | The sentence inside parentheses? It is there to clarify that there is no obligation to provide a pointer to an object that has just been initialized by pthread_attr_init(), the latter may have been used for other purposes in the meantime (e.g., such as specifying attributes to use for some threads, before asking later for the current values). | |
| 70 | I don't think so. This is already guaranteed by the limited changes of D43329 and arguably should be as a matter of good interface design (it falls under POLA according to me). I would agree with you if it had to come with a huge performance hit or overly complicated code, but that isn't the case here. | |
| share/man/man3/pthread_attr_get_np.3 | ||
|---|---|---|
| 57–71 | So why not say directly that calls to pthread_attr_get_np() with the same pattr object do not require re-initialization? | |
| share/man/man3/pthread_attr_get_np.3 | ||
|---|---|---|
| 58 | Or clarify what you mean by "regularly". | |
Comment Actions
Rework the part on the lifecycle pointed to by dst.
| share/man/man3/pthread_attr_get_np.3 | ||
|---|---|---|
| 57–71 | I think this is not general enough to convey what I would like to. My initial formulation doesn't seem to be much better. Also, I would like to avoid repeating what belongs to pthread_attr(3) (but is not even there). I've updated the revision with a new one. What do you think? | |
| 58 | (This has been rewritten anew.) | |
| share/man/man3/pthread_attr_get_np.3 | ||
|---|---|---|
| 70 | It is too cumbersome to maintain, and does not give much benefits to users that typically alloc/get/dealloc. | |
| share/man/man3/pthread_attr_get_np.3 | ||
|---|---|---|
| 70 | pthread_attr_get_np()'s code is not the simplest, but I don't find it very cumbersome either. And the previous significant revision of this function is dated... 2010. I don't think we'll have to change it at all in the next 10 years, except as a consequence of changes I may make in the course of the "priorities" project or as a follow-up. So... | |