Radiance-dev digest, Vol 1 #19 - 3 msgs

Schorsch writes:

Ok, independently of the specific implementation details, I see
the following strategies that we could test:

Of these, I like the following solutions the best:

System lock (as implemented for unix)
* direct read access to ambient file
* direct write access to ambient file
* locking through fcntl() (resp. the standard Windows locking
   mechanisms, translated through Samba when needed)

Simple lock file
* direct read access to ambient file
* direct write access to ambient file
* locking through lock file, broken after a TTL of n minutes

Unidirectional data server
* direct read access to ambient file
* ambient data written through server process
* server may use one of the above locking mechanisms if file
   writing is still shared with other processes, or none if it
   has exclusive access

I presume by the "system lock" you mean the one we have now, and I'd like to keep this around (or some variant of it) for systems with working lock managers, or for a fantastic future when NFS finally gets its act together and fixes their lockd implementation.

Of the various servers suggested, the unidirectional data server makes the most sense to me, particularly if it can be run on the file server machine. That way, the network traffic is no worse than it was, and since most of the ambient file i/o is read calls, the server has much less chance of being overwhelmed than a bidirectional server would.

However, there is another advantage to the locking mechanisim approach, which is that we need it also for rpiece, which we haven't talked about. Having one solution we could put in the library for making and breaking file locks would be great!

-Greg