jimzah/freebsd-src
1
0
Fork 0
mirror of https://github.com/freebsd/freebsd-src.git synced 2024-12-03 08:22:44 +00:00
Code Issues Actions 2 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.