There are two major sources of suboptimal hit rate on Wikipedia which
relate to the Vary header:
* In Accept-Encoding, we only care whether "gzip" is present or not, but
IE and Firefox use different whitespace conventions and so each get
separate entries in the cache
* We only care whether the
On Fri, 2008-02-08 at 15:52 +1300, Amos Jeffries wrote:
> The second;
> sockaddr_storage (as Husni uses, and Adrian mentioned) was created to
> provide a better way of using sockaddr* so the sockaddr_in and
> sockaddr_in6 bits could be read-written easily. But the big/litte endian
> problems betw
On Fri, 2008-02-08 at 16:10 +1300, Amos Jeffries wrote:
> > Too bad compilers produce different output for each execution due to
> > timestamps and such.
>
> What do you mean by this? A standard entry-level compiler test is that it
> produces the same output from the same input every time.
The "s
> On Fri, Feb 08, 2008, Amos Jeffries wrote:
>
>> sockaddr_storage (as Husni uses, and Adrian mentioned) was created to
>> provide a better way of using sockaddr* so the sockaddr_in and
>> sockaddr_in6 bits could be read-written easily. But the big/litte endian
>> problems between OS screwed up th
> On Fri, 2008-02-08 at 14:31 +1300, Amos Jeffries wrote:
>> > On Wed, 2008-02-06 at 21:26 +0200, Tsantilas Christos wrote:
>> >> Do we need something like that? Any comments/suggestions? Any
>> testers?
>> >
>> > I believe we do and I appreciate you working on it! Please try to fix
>> > the remain
On Fri, Feb 08, 2008, Amos Jeffries wrote:
> sockaddr_storage (as Husni uses, and Adrian mentioned) was created to
> provide a better way of using sockaddr* so the sockaddr_in and
> sockaddr_in6 bits could be read-written easily. But the big/litte endian
> problems between OS screwed up the socka
> On Fri, 2008-02-08 at 11:46 +1300, Amos Jeffries wrote:
>
>> The basics:
>>
>> addrinfo* extends the neutral sockaddr* type ( union { sockaddr_in,
>> sockaddr_in6, sockaddr_storage} ) while adding the size values and
>> moving the flags and protocol details.
>
> Hi Amos,
>
> I understand th
On Fri, 2008-02-08 at 14:31 +1300, Amos Jeffries wrote:
> > On Wed, 2008-02-06 at 21:26 +0200, Tsantilas Christos wrote:
> >> Do we need something like that? Any comments/suggestions? Any testers?
> >
> > I believe we do and I appreciate you working on it! Please try to fix
> > the remaining proble
> On Wed, 2008-02-06 at 21:26 +0200, Tsantilas Christos wrote:
>> Do we need something like that? Any comments/suggestions? Any testers?
>
> I believe we do and I appreciate you working on it! Please try to fix
> the remaining problems Amos pointed out.
>
> Also, can you apply it to the entire Squi
On Wed, 2008-02-06 at 21:26 +0200, Tsantilas Christos wrote:
> Do we need something like that? Any comments/suggestions? Any testers?
I believe we do and I appreciate you working on it! Please try to fix
the remaining problems Amos pointed out.
Also, can you apply it to the entire Squid tree, rem
On Fri, 2008-02-08 at 11:46 +1300, Amos Jeffries wrote:
> The basics:
>
> addrinfo* extends the neutral sockaddr* type ( union { sockaddr_in,
> sockaddr_in6, sockaddr_storage} ) while adding the size values and
> moving the flags and protocol details.
Hi Amos,
I understand that we need to
>
>> Tested.
>>
>> I have made a (small) file of the structures I've noticed past
>> formatting
>> errors on. With a manual fix-up to what I think it should look like in
>> readable C++ under the published squid formatting description.
>>
>> The output of your script does this:
>> .
> And which version of debian on which platform is showing the busted
> behaviour?
>
Dell i386
Kernels 2.6.18-4 thru 2.6.22-2
libstdc6 with g++ 4.1 thru 4.3
All the debian setups I have had to test with basically since I first
found it.
Amos
>
> On Fri, Feb 08, 2008, Amos Jeffries wrote:
>>
And which version of debian on which platform is showing the busted behaviour?
Adrian
On Fri, Feb 08, 2008, Amos Jeffries wrote:
> >
> > On Thu, 2008-02-07 at 12:21 +0900, Adrian Chadd wrote:
> >>
> >> Well, I haven't removed the temporary malloc/free pair, whatever its
> >> called;
> >> I've j
> On Fri, Feb 08, 2008, Amos Jeffries wrote:
>
>> Try it. You will be horrified.
>
> Why? Whats being trashed, AI, or AI->somemember?
AI->somemember.
>
> If AI is being trashed, then just create a temporary pointer copy
> of AI, use that in the socket call, and then throw it away.
> if its trashi
On Fri, Feb 08, 2008, Amos Jeffries wrote:
> Try it. You will be horrified.
Why? Whats being trashed, AI, or AI->somemember?
If AI is being trashed, then just create a temporary pointer copy
of AI, use that in the socket call, and then throw it away.
if its trashing the memory -at- the AI rather
> Have you tried running valgrind?
>
> Also, wait. What exactly are you using addr_info for? Can you explain it
> to me?
The basics:
addrinfo* extends the neutral sockaddr* type ( union { sockaddr_in,
sockaddr_in6, sockaddr_storage} ) while adding the size values and
moving the flags and protoc
> Uhm, the kernel won't be free'ing userland memory at all; it doesn't give
> a rats how its managed.
>
> You're probably confused with the library - the libc is fumbling with
> all the struct addrinfo things.
Possibly. Once an external call is made I no longer care if its kernel or
library. Bad
Have you tried running valgrind?
Also, wait. What exactly are you using addr_info for? Can you explain it
to me?
There's a netural sock addr size type - its called sockaddr_storage.
addr_info is for return results from hostname<->ip queries..
Adrian
On Fri, Feb 08, 2008, Amos Jeffries wrote:
>
> On Thu, 2008-02-07 at 14:08 +0900, Adrian Chadd wrote:
>> On Thu, Feb 07, 2008, Robert Collins wrote:
>>
>> > > Still, this is one of those "death of a thousand cuts" method of
>> > > killing performance..
>> >
>> > Right, I haven't seen the commit; care to mail the diff?
>>
>> Which? I just lo
Uhm, the kernel won't be free'ing userland memory at all; it doesn't give
a rats how its managed.
You're probably confused with the library - the libc is fumbling with
all the struct addrinfo things.
Also, if the bug bugs you, create a temporary pointer and pass that in. ;)
Adrian
On Fri, Feb
> On Thu, Feb 07, 2008, Robert Collins wrote:
>
>> > Still, this is one of those "death of a thousand cuts" method of
>> > killing performance..
>>
>> Right, I haven't seen the commit; care to mail the diff?
>
> Which? I just looked at the places where Amos is calling GetAddrInfo()
> and FreeAddrIn
>
> On Thu, 2008-02-07 at 12:21 +0900, Adrian Chadd wrote:
>>
>> Well, I haven't removed the temporary malloc/free pair, whatever its
>> called;
>> I've just removed Amos' workaround in src/comm.cc so it doesn't leak
>> on my
>> system whilst I profile.
>>
>> Still, this is one of those "death of a
> Tested.
>
> I have made a (small) file of the structures I've noticed past formatting
> errors on. With a manual fix-up to what I think it should look like in
> readable C++ under the published squid formatting description.
>
> The output of your script does this:
> ..
It is
24 matches
Mail list logo
