-
Notifications
You must be signed in to change notification settings - Fork 967
Tweak nolock function descriptions #5015
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
Tweak nolock function descriptions #5015
Conversation
@Rageking8 : Thanks for your contribution! The author(s) have been notified to review your proposed change. |
PRMerger Results
|
Learn Build status updates of commit f5a3d28: ✅ Validation status: passed
For more details, please refer to the build report. For any questions, please:
|
PRMerger Results
|
@@ -11,7 +11,7 @@ helpviewer_keywords: ["_ungetch function", "ungetwch function", "characters, pus | |||
--- | |||
# `_ungetch`, `_ungetwch`, `_ungetch_nolock`, `_ungetwch_nolock` | |||
|
|||
Pushes back the last character that's read from the console without locking. | |||
Pushes back the last character that's read from the console. |
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.
Reverted the addition of "without locking" as this article holds both normal and nolock variants of ungetch
.
Can you review the proposed changes? When the changes are ready for publication, add a #label:"aq-pr-triaged" |
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.
I agree with you. I think this is an improvement and that being less prescriptive about what exactly is being locked is clearer. Developers will know what locking means in this content.
Thank you for these updates.
#sign-off |
The wording "locking the thread" seems a little off since it should either be "locking the stream" or some other "item". Omitting the "item" being locked seems to work the best at the expense of being less "specific" (as compared to using the phrase "locking the stream" etc). The large majority of locking for the normal analog of
_nolock
APIs are done via_lock_file
with aFILE*
for the stream, with some others being done via__acrt_lock
with__acrt_conio_lock
of type__acrt_lock_id
(both locking functions are implemented usingEnterCriticalSection
) (the term "locking the stream" cannot be used for all_nolock
APIs). Hence, using the generic term "without locking" for all applicable_nolock
APIs make things uniform and the idea of "not locking" is decently conveyed.@TylerMSFT Does this sound like an improvement? Happy to hear some feedback.
Note 1) Some descriptions (e.g.
_fseek_nolock
) are identical to their normal analog, therefore the notion of "not locking" is added.Note 2) The descriptions of
_getdcwd_nolock
and_wgetdcwd_nolock
are not modified as they are just macros to the normal analog.