Aucb.548
fa.editor-p
utcsrgv!utzoo!decvax!ucbvax!C70:editor-people
Sun Feb 28 11:11:05 1982
Concurrent File Access
>From ARK@SU-AI Sun Feb 28 11:07:39 1982
[ Editor's note: the following message, though somewhat specific to
Twenex Emacs, raises issues of human interface that are of general
interest. What do members of EDITOR-PEOPLE think the most convenient
strategy is for avoiding concurrent-access problems? /jqj ]
[ITS and Twenex] EMACS has the problem that two people, unbeknownst to
each other, can be updating a file concurrently. If both of them try to
save their changes, the second one will get the message that the file has
changed. This second person has the option of overwriting the first
writer's changes or of saving his own changes elsewhere. This is the same
as the classical concurrent database access problem. The classic database
solution is to introduce locking.
I propose the following semantics.
These new functions be created:
1. Attempt to write lock a file name. The lock request fails of the file
name is locked by by another fork or job or if the file has been changed
since it has been read. Status is returned to indicate whether the file
name was successfully locked (or who has it if not). This only locks out
other attempts to write lock the file name, but does not affect the file
system. That is, the file may still be read by other programs.
2. Release a write lock on a file name. The write lock is released if it
is owned. Status is returned to indicate whether the lock had been owned.
Again, this does not affect the file system.
3. Inquire on the lock status of a file name. Returns the status message
that would be returned by function "1--obtain a write lock".
4. Read and write lock a file. Same as "1--obtain a write lock" followed
by an exclusive open of the file. This affects the file system. The
write lock is released if the exclusive open fails.
User functions:
A user specifies whether a file is to be read only or updated as well when
the user visits a file (e.g., different visit commands are used for each).
[Uses operation "3--lock inquiry".]
User attempts to update a buffer for the first time (that is, sets the "*"
update flag) if the file was read in "update mode". Attempt to write lock
the file name. [Uses operation "1".]
User saves file. Different commands are used to indicate that this is the
final change (release lock, operation "2") or a checkpoint (no change to
lock status).
User exits or visits a new file in "paranoid" mode. Ask user whether
buffers with changes should be saved and whether locked buffers should be
unlocked (operation "2"). It would be nice if a series of kills followed
by a yank that result in an unchanged buffer cause reset of the "buffer
changed" flag. (No need to release a lock, though.)
User needs to repair a file and wants to make sure that no one else can
look at it or change it. User explicitly issues command to invoke
operation "4" after visiting the file.
All of these would be new functions that could be mapped onto existing
keyboard commands if specified by a particular individual's EMACS.INIT.
Thus, it could easily be "upward compatible".
Comments and ideas are solicited. Feel free to disseminate this message.
Offers of help are most welcome.
Arthur
-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <
[email protected]>
of
http://communication.ucsd.edu/A-News/
This Usenet Oldnews Archive
article may be copied and distributed freely, provided:
1. There is no money collected for the text(s) of the articles.
2. The following notice remains appended to each copy:
The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996
Bruce Jones, Henry Spencer, David Wiseman.
