diff options
| author |  edward <edward@web> | 2015-11-14 09:57:40 +0000 |
|---|---|---|
| committer |  admin <admin@branchable.com> | 2015-11-14 09:57:40 +0000 |
| commit | 1d8a033579d9247fe1410409d01ac9e38ba0a445 (patch) | |
| tree | 4993f5fce3664fac327cf14fd7ddcd8bd625bf20 | |
| parent | 00680a37a9881c8fc1c234ea47ba37bf31ad4c18 (diff) | |
fix typo
| -rw-r--r-- | doc/devblog/day_336__pid_locks.mdwn | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/doc/devblog/day_336__pid_locks.mdwn b/doc/devblog/day_336__pid_locks.mdwn index c59e64442..03ca076e6 100644 --- a/doc/devblog/day_336__pid_locks.mdwn +++ b/doc/devblog/day_336__pid_locks.mdwn @@ -13,7 +13,7 @@ because then the pid in question can be running on a different computer. Even if you do figure out that a pid lock is stale, how do you then take over a stale pid lock, without racing with anther process that also wants to take it over? This was the truely tricky question of the -day.. +day. I have a possibly slightly novel approach to solve that: Put a more modern lock file someplace else (eg, /dev/shm) |