Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!convex!thurlow From: thurlow@convex.com (Robert Thurlow) Newsgroups: comp.lang.perl Subject: Re: lockf mods Message-ID: Date: 2 Feb 91 14:48:28 GMT References: <1991Jan31.203029.12599@sdd.hp.com> <1991Feb1.074602.25583@robobar.co.uk> Sender: news@convex.com (news access account) Organization: Convex Computer Corporation, Richardson, Tx. Lines: 23 Nntp-Posting-Host: dhostwo.convex.com In <1991Feb1.074602.25583@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: >Hmm.. but wouldn't it make perl programs more portable if >you actually implemented the perl flock() function with lockf() ? >(Or don't the idioms match ? I haven't got a flock(2) manual page ....) I know of no BSD/Sun based machines which support any form of mapping between flock() and lockf(). An flock() style file lock does not in any way prevent someone from locking either a file region or an entire file with lockf(), or vice versa. Yes, this is stupid. Yes, the two locks can be mapped. But they've not been as far as I know. Anyone can jump in here to point out counterexamples with my thanks. What's the take on this in the System V universe? The last System V machine I worked on supported only lockf()/fcntl() style locking, with either advisory or enforcement locks as a kernel tunable. flock() is really a pretty limited idiom, so I never saw motivation to port it to SysV. The big reason it's so popular on BSD/Sun machines is that the Sun lock manager has traditionally been fraught with reliability problems. Rob T -- Rob Thurlow, thurlow@convex.com An employee and not a spokesman for Convex Computer Corp., Dallas, TX