@@ -81,7 +81,7 @@ data {-# CTYPE "struct group" #-} CGroup
81
81
-- setpwent(3) and closed via endpwent(3). Only one thread at
82
82
-- a time can safely iterate through the file.
83
83
--
84
- -- * On MacOS (through Catalina 10.15), there is no getpwent_r(3) or
84
+ -- * On macOS (through Catalina 10.15), there is no getpwent_r(3) or
85
85
-- getgrent_r(3), so a lock is also required for safe buffer sharing.
86
86
--
87
87
-- * On FreeBSD, in the default configuration with passwd lookups configured
@@ -95,7 +95,7 @@ data {-# CTYPE "struct group" #-} CGroup
95
95
-- and @*(nam|[ug]id)_r(3)@ functions in the /same/ thread.
96
96
--
97
97
-- * Despite rather similar manpages for getpwent(3) and getpwnam(3), ... as
98
- -- on FreeBSD, the above issue is not seen on NetBSD or MacOS .
98
+ -- on FreeBSD, the above issue is not seen on NetBSD or macOS .
99
99
--
100
100
-- This is not an issue with 1-to-1 thread models, where the code executing
101
101
-- @get(pw|gr)ent@ has exclusive use of its thread, but it is a real issue
@@ -109,7 +109,7 @@ data {-# CTYPE "struct group" #-} CGroup
109
109
-- non-trivial. In the threaded runtime, we can run these functions in a
110
110
-- /bound thread/ (via 'forkOS'), thereby avoiding the FreeBSD issues. We
111
111
-- still need a lock to serialise multiple threads calling these functions
112
- -- on at least MacOS for lack of @_r@ equivalents. While on FreeBSD we could
112
+ -- on at least macOS for lack of @_r@ equivalents. While on FreeBSD we could
113
113
-- use @getpwent_r(3)@ and @getgrent_r(3)@ in a bound thread without any
114
114
-- locks, implementing this special case is likely not worthwhile.
115
115
--
0 commit comments