Fresh patch for Solaris
jesus at omniti.com
Mon Aug 11 15:37:39 CEST 2008
On Aug 11, 2008, at 5:30 AM, Poul-Henning Kamp wrote:
> In message <57710936-1C6F-457E-AA6D-6BB40DB2CF06 at omniti.com>, Theo
> OK, I've picked the obvious stuff out.
> Various questions about the rest:
> Doesn't Solaris have fcntl(F_SETLK) as mandated by POSIX ?
> flock() is not a standardized API, and I havn't seen a system yet
> which supports it, which doesn't also have fcntl(F_SETLK), so I
> would rather not mess up the source with a pointless check.
Ah, good catch. That wasn't a patch for Solaris. It was for Linux.
We've run into some issues with flock being more reliable than fcntl
on Linux under high concurrency environments. We ran into this
problem on another project and thought to make a preemptive strike in
However, my patch prefers flock over fcntl, which is clearly wrong as
it might do that on BSD*. flock() on Solaris is only available with -
lucb (the meager BSD-ish compatibility layer). So, with that patch,
Solaris still uses fcntl. (Go POSIX!)
The ugly way we did it on the other project (FastXSL) that had this
issue is here:
> Do you know for sure that sendfile on Solaris has no reference to the
> relevant parts of the file when it returns ? Otherwise it is not safe
> to use.
I asked the internal engineering team at Sun, they said that it has no
references. I asked move forcefully and they did a code review
(albeit very short) and said again that it had no references. So, at
this point, I believe that it is safe to use in Varnish.
> Why is the extra include of <sys/statvfs.h> necessary in
> storage_file.c ?
My mistake. I wasn't thorough when I merged up to trunk. No conflict
and my lack of attention. Ignore that.
> Is there a reason to name the shared object .so instead of .o or is it
> just cosmetics ?
The Sun Studio toolchain barfs on the .o. It "knows better" and seems
to ignore the request to make it shared. I could get around this with
a shell scripts (as you had once suggested), but this change makes it
work in all the toolchains I have tried "out of the box"
> In cache_acceptor.c, please implement the "->pass" function which does
> the port_send() call.
Will do. Not sure how that got reverted actually.
> Why the initialization in mgt_child.c ?
I believe that is left over from something else. A valgrind warning
-- but that could only have been due to other code I added and then
removed. It looks clean and safe without initialization.
Esoteric Curio -- http://lethargy.org/
OmniTI Computer Consulting, Inc. -- http://omniti.com/
More information about the varnish-dev