Comment 117 for bug 93546

> So what should FirefoxB do when FirefoxA has the history file locked and it
> wants to update it? Queue those things for later? Block the UI? How should
> it communicate to the calling code that the write it wanted didn't really
> complete? How to keep other code in that app from reading stale data?

By designing your data store to be as nonblocking as possible.

Compare mailbox (one huge file with all your mails glued together)
and maildir format.

In mailbox, deletion of one email is a blocking operation - you must
prevent other processes from sseing half-updated file, and it also
may take arbitrary amount of time (think 2GB mailbox).

Zillions of mails stored in maildir directories can be read, written,
moved, deleted etc concurrently by any number of independend processes,
even from different machines! All what is needed is atomic rename().

I agree that relying on locking is a bad idea.
Networked filesystems+locking => bugs, bugs, bugs, bugs, bugs.