Re: Bug #2167: configure incorrectly identifies flock() as available

>>>>> "Sascha" == Sascha Schumann <sascha@schumann.cx> writes: Sascha> I don't see any advantage in using our flock() Sascha> emulation over Solaris' fcntl() wrapper. Our wrapper Sascha> depends as well on fcntl(). If you're going to encapsulate the lock routines you should write a single lock function, and use it. The problem with providing an emulated flock is that people will often just call flock and assume they are getting the real thing. Specifically, they may be assuming that flock will work over NFS. This may not be the case if flock actually wraps lockf or fcntl. And nobody is going to be expecting the fcntl behaviour of releasing all locks on a file if *any* descriptor pointing at that file goes away. When dealing with locks, you must code to the actual interface being used. Doing otherwise introduces incorrect behaviour that can be very difficult to debug. I didn't spot the flock wrapper in php_compat.c the first time around. My intention for the patch was to make the code not use flock at all on Solaris. I realize this is a pain in the butt. The only really portable solution (for UNIX), is to just write to the lowest common denominator and use fcntl. It's braindead, but at least you don't get any surprises (you have to code to the brokenness inherent in fcntl). In the long term this has eliminated quite a few "side effect" bugs caused by assuming true flock semantics in what turned out to be a fcntl-wrappered environment. If nothing else, if PHP *does* fall back to emulating flock over fcntl (specifically), it would be useful to have a #warning in the compile stating that using flock might not work as expected. --lyndon