If we're going to hold the lock, it can be useful to scribble down the
pid that we spawned off to quickly associate the lock back to the
process that's keeping it open.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 65055 Build 61938: arc lint + arc unit
Event Timeline
| usr.bin/lockf/lockf.c | ||
|---|---|---|
| 263 | Why not just (void)dprintf(lockfd, "%d\n", child)? | |
| usr.bin/lockf/lockf.c | ||
|---|---|---|
| 263 | I didn't think I really wanted the extra complexity, but looking at the implementation it doesn't seem to be as bad as I was afraid it might be | |
| usr.bin/lockf/lockf.c | ||
|---|---|---|
| 94 | I would prefer if the flags were bools but that's cosmetic. | |
| usr.bin/lockf/lockf.c | ||
|---|---|---|
| 94 | Yeah, I was eyeballing both this and perhaps the 'kill(getpid(), ....)` pattern in the signal handler for a cosmetic pass. | |
| usr.bin/lockf/lockf.c | ||
|---|---|---|
| 124 | Adding some flags |= O_TRUNC here as well, in case we're rolling with -k. | |