On Sun, 2002-01-06 at 07:27, Darin Adler wrote: > On 1/4/02 7:31 PM, "Frank Worsley" <fworsley shaw ca> wrote: [...] > > 3. Why is NautilusMetafile a CORBA object? Is the reason so that it can > > be accessed by other applications and programming languages or is there > > some other reason? > > Just as the metadata.html document says, "implementation will have to be > written in a ``thread-safe'' manner as multiple applications could > potentially access the metadata database concurrently". Using a shared > server to read and write the metadata is a basic way to make sure this works > for all processes on one machine. For directories shared across multiple > machines, say with NFS, this scheme is insufficient. > > The CORBA object was created as a practical fix for real problems we were > seeing in the late beta versions of Nautilus before 1.0. One Nautilus > component would write to metadata, and the other Nautilus components on the > same machine wouldn't notice the change and were likely to overwrite it. > > I would welcome an improved scheme for shared access to the metadata. I'm probably missing something, but you can do atomic read and write from differents process / differents thread. The writing thread should specify O_APPEND in the open() flags, so that each write atomically change the file offset to the current file size. Another thread / process may use a different file descriptor, opened for reading the same file. Theses two descriptor won't share the same file table entry. You could also have a look at the pread() and pwrite() function that allow you to specify an offset, and that don't change the file offset in the file table. Which allow you to atomically read and write to the same file descriptor. Unfortunally, this one is not portable. -- Yoann Vandoorselaere http://www.prelude-ids.org
Attachment:
pgp1ciKPOm8ax.pgp
Description: PGP signature