Skip to content

Add units to timeout argument in EventFlags #9670

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

Merged
merged 1 commit into from
Feb 21, 2019

Conversation

kegilbert
Copy link
Contributor

@kegilbert kegilbert commented Feb 11, 2019

Description

Add units to the timeout argument in wait_all/any:

#8894

Pull request type

[ ] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[X] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

@sarahmarshy
@AnotherButler

@kjbracey
Copy link
Contributor

This phrasing occurs in quite a lot of other RTOS header files, as they were a copy-and-paste from CMSIS-RTOS docs (but might be CMSIS-RTOS v1 rather than v2?). Would be worth updating the others if doing EventFlags, as I think consistency is important here - they all have exactly the same time concept.

I can immediately think of Thread, ThisThread, Semaphore, Mutex, possibly ConditionVariable.

As a sort of compromise, some of those seem to have kept the phrasing, but renamed the timeout variable to millisec.

@kegilbert
Copy link
Contributor Author

@kjbracey-arm It looks like everything else in rtos uses the millisecond parameter name with the old description. I'm not as much of a fan of this since I find it's a bit strange to name the variable after the units and not what it does but as everything uses that I could instead change the EventFlag parameter to millisecond for consistency.

@0Grit
Copy link

0Grit commented Feb 12, 2019

#9077

Edit: Lightly related issue

@cmonr
Copy link
Contributor

cmonr commented Feb 13, 2019

@loverdeg-ep Mind elaborating on your single-link comment?

@0Grit
Copy link

0Grit commented Feb 13, 2019

@loverdeg-ep Mind elaborating on your single-link comment?

Kind of a personal note I suppose. Like to be able to retrace interesting & related conversations for my future self.

I'll cut it out if causing trouble.

Copy link
Contributor

@kjbracey kjbracey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per comment above, I'm going to request that this be made consistent across the rtos classes.

I don't mind whether you change this to match the others, or change all the others to match your new form here - others can express a preference.

@cmonr
Copy link
Contributor

cmonr commented Feb 13, 2019

I'll cut it out if causing trouble.

Nah, no need. That's fine.

@cmonr
Copy link
Contributor

cmonr commented Feb 20, 2019

@kegilbert Any progress?

@kegilbert
Copy link
Contributor Author

Yup, updating this today.

Matches rest of RTOS class timeout parameters by using the unit name. Remove ambigious statement in reference to 0 ms being no-timeout as a timeout of 0 causes the function to not block and return immediately (osWaitForever is used as no timeout as it will wait forever)
@kegilbert
Copy link
Contributor Author

I additionally removed the or 0 in case of no timeout segments from the comments as that implied the opposite of what a timeout of 0 actually did to me (no timeout to me sounds like the function will never timeout which is what osWaitForever will do).

@param millisec Timeout value or 0 in case of no timeout (default: osWaitForever).

As we had in Mail.h in particular threw me off. Feel free to let me know if you disagree, I can change that back if need be.

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 21, 2019

CI started

@mbed-ci
Copy link

mbed-ci commented Feb 21, 2019

Test run: SUCCESS

Summary: 12 of 12 test jobs passed
Build number : 1
Build artifacts

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants