Fresh patch for Solaris

[Theo Schlossnagle]

On Aug 11, 2008, at 5:30 AM, Poul-Henning Kamp wrote:

> In message <57710936-1C6F-457E-AA6D-6BB40DB2CF06 at omniti.com>, Theo  
> Schlossnagle
> writes:
>
>> http://lethargy.org/~jesus/misc/varnish-solaris-trunk-3071.diff
>
> 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  
Varnish.

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:

http://labs.omniti.com/trac/fastxsl/changeset/43

>
> 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.

--
Theo Schlossnagle
Esoteric Curio -- http://lethargy.org/
OmniTI Computer Consulting, Inc. -- http://omniti.com/