CODING_STYLE: document why O_NONBLOCK makes sense when opening regular files, too
This commit is contained in:
parent
106f12a08f
commit
fda8a89046
|
@ -440,3 +440,13 @@
|
||||||
string, always apply the C-style unescaping fist, followed by the specifier
|
string, always apply the C-style unescaping fist, followed by the specifier
|
||||||
expansion. When doing the reverse, make sure to escape '%' in specifier-style
|
expansion. When doing the reverse, make sure to escape '%' in specifier-style
|
||||||
first (i.e. '%' → '%%'), and then do C-style escaping where necessary.
|
first (i.e. '%' → '%%'), and then do C-style escaping where necessary.
|
||||||
|
|
||||||
|
- It's a good idea to use O_NONBLOCK when opening 'foreign' regular files, i.e
|
||||||
|
file system objects that are supposed to be regular files whose paths where
|
||||||
|
specified by the user and hence might actually refer to other types of file
|
||||||
|
system objects. This is a good idea so that we don't end up blocking on
|
||||||
|
'strange' file nodes, for example if the user pointed us to a FIFO or device
|
||||||
|
node which may block when opening. Moreover even for actual regular files
|
||||||
|
O_NONBLOCK has a benefit: it bypasses any mandatory lock that might be in
|
||||||
|
effect on the regular file. If in doubt consider turning off O_NONBLOCK again
|
||||||
|
after opening.
|
||||||
|
|
Loading…
Reference in a new issue