Re: Re: Source Request
By: tracker1 to Deuce on Tue Nov 17 2015 07:25 pm
Pulling that in to something else that's not based around the DOS share modes would be a mistake IMHO. Synchronet has a long history of using SHARE stuff, so it makes sense to emulate that on other OSs. This likely does NOT make sense for libuv.
Fair enough, but isn't range locking important to interoperate
with different programs (such as synchronet)? If I use node's
shared read/write access and don't do any locking, won't
things potentially mess up?
Both range locking and file locking can be necessary to interoperate with Synchronet.
In the general case, the program that "owns" the file defines the synchronization mechanism. Synchronet used file locking for some and record locking for others, and even both for some files. On a single OS (ie: DOS or Windows), this worked out fine... but the record and file locking semantics are different between Windows and *nix, so Windows semantics are emulated on *nix (since the code was written for Windows).
A further issue is that not all *nix file systems support both record and file locking, resulting in them being emulated with each other sometimes (and dotfile locking being used some other places).
Yet ANOTHER issue is that some systems support madatory locking (once it's locked, operations like write() fail) and others support advisory locking (only locks are blocked, so everyone has to call lock). Some support both as an option during the lock operation, and some support both, but only one type for a specific file system.
A particularly bad thing about *nix fcntl() locks is that if any thread in the process closes a file, ALL LOCKS held on that file are lost - even if they have a different file handle (thread1 opens "/tmp/temp" and locks the first byte, thread2 opens "/tmp/temp" and locks the second byte, thread1 closes "/tmp/temp", and thread2 no longer has the second byte locked).
The UAV issue 318 you mentioned seems to have a cross-platform locking API already, so using that should work.
Regarding the locked read/write functions mentioned in node.js issue #1426, those functions would be mostly useless... the idea is that that you lock a record to prevent anyone else from changing it for a period of time. The most common usage is if you're going to update it... you lock the record, read it, modify it, write it, then unlock it. If the lock only protects the read and the write, you can end up losing changes someone else did while you modified your copy.
---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
Mro is an idiot. Please ignore him, we keep hoping he'll go away.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)