d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Remove the claim that UUCP locking were not atomic. It is since

Browse Source 
revision 1.8 of uucplock.c.
This commit is contained in:
Joerg Wunsch 1997-10-07 07:24:50 +00:00
parent a73927ee24
commit cfeb4fd273
Notes: svn2git 2020-12-20 02:59:44 +00:00 
svn path=/head/; revision=30196
1 changed files with 1 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
lib/libutil/uucplock.3
View File

@ -23,7 +23,7 @@
.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
.\"
.\" $Id: uucplock.3,v 1.8 1997/08/10 18:42:38 ache Exp $
.\" $Id: uucplock.3,v 1.9 1997/09/29 19:11:25 wosch Exp $
.\" "
.Dd March 30, 1997
.Os
@ -151,18 +151,6 @@ for further details.
.Xr read 2 ,
.Xr write 2
.Sh BUGS
Locking is not atomic. Should a race condition occur, it's
possible that the
.Dq losing
process fails to identify the
.Dq winning
process. If this happens,
.Fn uu_lock
returns
.Dv UU_LOCK_READ_ERR
and errno is set to
.Er EINVAL .
.Pp
It is possible that a stale lock is not recognised as such if a new
processes is assigned the same processes id as the program that left
the stale lock.