Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On Sat, 8 Apr 2006 17:20:50 -0400 "Gordon Marx" <gcmarx at gmail.com> wrote: > Two notes: on Linux, lockf(3) is fcntl(2), and an fcntl(2) "lock" is > advisory, so an ill-behaved program will ignore it and write with > impunity. This is also true. You can also include most commercial Unixes in the above comment. When I had to rewrite the utmp library functions, it was important to find out if any code we supplied wrote to utmp (and utxtmp) directly rather than through the utmp library functions. The original problem was that we were using a lock file, but that approach failed when there were cases of a large number of simultaneous logins (about 1000). The way utmp processing worked, we kept the file unlocked for the first pass. This was acceptable because if we found the process' record, that was unique to the process. Our first lock was to use lockf(3), but on a diskless system, we would hang because lockf(3) required portmapper and the lock daemon, which were not running when init(8) first asserted the lock. We then decided to use flock(2) because the utmp file is always local to the processor. Actually, we ended up writing our own system call because the semantics changed on flock(2) because of clustering. -- Jerry Feldman <gaf at blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.blu.org/pipermail/discuss/attachments/20060409/717c53f8/attachment.sig>
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |