Do calls to storage Load need to be Lock protected?

[elee1766]

by contract, do calls to load need to be protected by the storage lock?

from what I see, the lock is used only to protect for simultaneous writes. it's not used to lock/protect the reader if a writer is currently writing.

is the caller supposed to take the Lock before reading the certificate? if not, are storage Load implementations supposed to protect for concurrent read/write access?

[elee1766]

Filestore uses os.WriteFile

// WriteFile writes data to the named file, creating it if necessary. 

// If the file does not exist, WriteFile creates it with permissions perm (before umask); 

// otherwise WriteFile truncates it before writing, without changing permissions. 

// Since WriteFile requires multiple system calls to complete, a failure mid-operation 

// can leave the file in a partially written state. 

func WriteFile(name string, data []byte, perm FileMode) error { 

	f, err := OpenFile(name, O_WRONLY|O_CREATE|O_TRUNC, perm) 

	if err != nil { 

		return err 

	} 

	_, err = f.Write(data) 

	if err1 := f.Close(); err1 != nil && err == nil { 

		err = err1 

	} 

	return err 

}

if reader reads while writefile is running. it could read after open file, which truncates the file, so it will read empty.

so I think there is a race and protection is needed.

within a process, read will force page cache flush if read is run after write before close, however between multiple processes. the file is empty from the opening of the file to fsync on close.

within the process, an rwmutex is needed likely. however between multiple processes, it may be prudent to require a global lock on read. if so, it may be correct to switch to a locking system with rw support in the long term (advisory lock, etc)

[elee1766]

https://github.com/containerd/containerd/blob/main/pkg%2Fatomicfile%2Ffile.go
maybe can do what containerd does