jesus at omniti.com
Tue Jan 8 21:06:30 CET 2008
On Jan 8, 2008, at 2:18 PM, Dag-Erling Smørgrav wrote:
> Theo Schlossnagle <jesus at omniti.com> writes:
>> We've been running this for a while on Solaris. Works really well.
> Only because you haven't noticed the bugs yet... for instance,
> session timeout is broken (commented out, actually) in your patch, so
> broken backends and / or clients will bog you down.
Sure. When I said "works well," I meant "as well as on Linux.
>> What we need is the function in cache_acceptor.c:
>> I see this as a cleaner mechanism regardless as there is no reason
>> the generic cache_acceptor to care about int vca_pipes; -- it's an
>> implementation detail. How's that sound?
> That sounds like a good idea. Even better if you can submit an
> isolated patch :)
Okay, I hadn't tackled that, I'll look at submitting a patch specific
>> sendfile and sendfilev on solaris
> Probably not a good idea unless sendfile() semantics are significantly
> better on Solaris than on FreeBSD and Linux.
It's sendfile, it has all the advantages of sendfile. To support
them, you have to conform to their APIs. I just added support so it
could say "oh, look, I know how to use that sendfile..." and then
actually use it (just as linux and freebsd now). And I think
sendfilev on Solaris is pretty slick.
>> using fcntl() when flock() is unavailable
> There are issues here as well; the semantics are subtly different from
> OS to OS. For instance, what happens if separate threads in the same
> process try to lock the same file? It's even less fun if you take
> into consideration systems that support both.
As I see it you only supported flock(). If I don't have it, I use
fcntl(). It will certainly not break any system that current works.
It doesn't use fcntl() when available.. it uses fcntl() only when
flock() isn't available. fcntl() on Linux acts really strange -- so
it would be bad -- as you intimate above.
OmniTI Computer Consulting, Inc.
P: +1.443.325.1357 x201
More information about the varnish-dev