On 02/14/2014 05:24 AM, Amos Jeffries wrote:
> Just to kick this further along. I've put together the proposal in patch
> form.
>
> Anyone game to test the SMP support is working properly with "-M
> foreground" when this is applied?
Not me, but it should be tested before commit IMO.
> I'm also
On 02/16/2014 08:42 PM, Amos Jeffries wrote:
> On 17/02/2014 2:56 p.m., Alex Rousskov wrote:
>> If my suggestion to add shutdown() and other methods to runners is
>> accepted, I can help with the corresponding adjustments (both trunk and
>> the proposed patch).
>>
>
On 02/19/2014 12:42 PM, Rajiv Desai wrote:
> On Wed, Feb 19, 2014 at 11:09 AM, Alex Rousskov
> wrote:
>> On 02/19/2014 03:11 AM, Rajiv Desai wrote:
>>> I am interested in adding functionality to squid to optionally add
>>> objects from PUT requests to cache. H
On 02/19/2014 03:11 AM, Rajiv Desai wrote:
> I am interested in adding functionality to squid to optionally add
> objects from PUT requests to cache. Has there been any related work
> done in the past or is being pursued currently that I can use as
> reference?
Just to make sure we are all on the
small caches. The larger your cache is, the more garbage it stores
(regardless of the value metric), and the less is the probability that
something valuable will be evicted when the cache is in a steady (full)
state.
HTH,
Alex.
> On Tue, Feb 18, 2014 at 10:30 PM, Rajiv Desai wrote:
>>
On 02/18/2014 04:11 PM, Rajiv Desai wrote:
> It seems like there is a bug where an object overwrites previously
> written object:
This is not really a bug -- hash collisions do happen, as you have
discovered and Rock store resolves them by overwriting older entries if
possible (or not caching the
On 02/18/2014 07:17 AM, Amos Jeffries wrote:
> You requested no more file renames until after auditing had finished. So
> that is leftover from previous rounds. The files are planned to be
> renamed and classes split according to source layout guidelines when the
> code is approved.
>
> If you ar
On 02/18/2014 10:45 AM, Kinkie wrote:
> But can we rely on std::mutex on windows? I suspect not, and the
> windows API as currently used are terrible.
Personally, I do not know the answer to that question and have no
reasonable means of testing possible answers to find out the correct
one. Perhaps
On 02/17/2014 11:16 PM, Francesco wrote:
>
> On 18 Feb 2014, at 00:44, Alex Rousskov
> wrote:
>
>> On 02/17/2014 02:46 PM, Kinkie wrote:
>>
>>> the attached patch aims at simplifying debug, making it also more
>>> effective.
>>
>> It
Here are a few more notes, to add to the unfinished review posted
earlier. The first and the last one are minor, but the rest is
serious/important.
On 01/05/2014 08:21 PM, Amos Jeffries wrote:
> +/// the protocol label for this message
> +const AnyP::ProtocolVersion & messageProtocol() c
specific names if needed.
That is all I had time for right now; will have to come back to this
later. My apologies if any of the above is half-cooked, but you wanted
me to send this before I break...
Cheers,
Alex.
> The parser still only parses the request-line and greps the mime headers
&g
On 02/17/2014 02:46 PM, Kinkie wrote:
> the attached patch aims at simplifying debug, making it also more effective.
It would be better to finish the discussion regarding the future of
debugging before making debugging-focused changes IMO.
> It:
> - removes some of the API cruft (ctx_enter, c
On 02/16/2014 06:51 AM, Kinkie wrote:
> Hi all,
> I'm working on debug together with Amos, working on reducing the
> size of the API, removing cruft and making it a bit speedier in the
> meantime.
> I'm looking into refactoring ctx_enter/ctx_exit into RAII, but right
> nw i can't remember ever se
On 02/16/2014 06:02 AM, Amos Jeffries wrote:
> This begins the shutdown sequence cleanup by creating a Runners Registry
> hook at the begining of the shutdown process.
Before the [adjusted version of] this patch goes in, we need to finish
the discussion started on the "[PREVIEW] cache_peer standby
On 02/13/2014 11:21 PM, Francesco Chemolli wrote:
>
> On 14 Feb 2014, at 06:31, Alex Rousskov
> wrote:
>
>> On 02/13/2014 03:47 PM, Amos Jeffries wrote:
>>> Use of "-N" with no parameter produce an error.
>>
>> I do not think we have to brea
On 02/13/2014 03:47 PM, Amos Jeffries wrote:
> Use of "-N" with no parameter produce an error.
I do not think we have to break existing scripts (some of which may
still be working OK!). We can issue a deprecation warning but treat bare
-N as "-N foreground" or equivalent.
> Perhapse making both -
On 02/13/2014 03:32 PM, Henrik Nordström wrote:
> tor 2014-02-13 klockan 09:43 -0700 skrev Alex Rousskov:
>
>> I am not sure which approach is the best, but I am sure we need to
>> clearly define and document the new semantics to avoid repeating -N
>> problems which were c
On 02/11/2014 03:16 PM, Amos Jeffries wrote:
> On 2014-02-12 11:07, Henrik Nordström wrote:
>> But seriously, it's a very small change to Squid. All systemd and the
>> like needs is that Squid stops all the backgrounding, setsid etc done in
>> watch_child(). The rest is business as usual, including
On 02/12/2014 04:40 PM, Amos Jeffries wrote:
> On 2014-02-13 10:36, Alex Rousskov wrote:
>> On 02/11/2014 04:49 AM, Kinkie wrote:
>>
>>> During recent discussion on IRC it was found out that there are not
>>> that many big patches queued for landing to trunk; it m
On 02/11/2014 04:49 AM, Kinkie wrote:
> During recent discussion on IRC it was found out that there are not
> that many big patches queued for landing to trunk; it may be a good
> moment to rework more aggressively at least part of the debugs()
> statements.
> I would like us to get a consensus o
Hello,
The attached patch avoids reconfiguration leak of [SSL] objects tied
to http_port and https_port.
This one-line change is rather controversial, and I am not sure it
should be accepted. The change fixes a true bug that causes a true
memory leak, but the rest of Squid code may not be rea
Hello,
The attached patch prevents TcpAcceptor job leaks on reconfiguration
by monitoring and reacting to the listening socket closure.
This monitoring does not happen automatically via COMM_ERR_CLOSING
because TcpAcceptor does not use comm_read and comm_write APIs. It has
to use the raw SetS
On 02/12/2014 01:41 AM, Kinkie wrote:
>> These provide some very useful info:
>> http://stackoverflow.com/questions/2027991/list-of-standard-header-files-in-c-and-c
>> http://www.cplusplus.com/reference/
>>
>> I would draw the line at ANSI C-style and C++ headers.
>>
>> Proposal:
>>
>> * system C h
On 02/11/2014 03:28 PM, Amos Jeffries wrote:
> On 2014-02-12 06:19, Kinkie wrote:
>> I suspect that HttpHeader.cc needs some love. Has anyone already
>> thought about this topic or should I prepare a proposal? I'd like to
>> share design ideas before going for an implementation attempt.
> Yes the
On 02/11/2014 04:48 AM, Kinkie wrote:
> The topic I'm thinking of is the policy of autoconf-detecting some
> system headers we use. While this is undoubtably good for C- and
> system- headers, it doesn't make much sense for pure C++ headers,
> which are very strongly defined by the standard and fo
On 02/10/2014 02:20 AM, Kinkie wrote:
>> The kind of cast appears to be wrong here: Const_cast<> is normally used
>> to remove const, not add it. It is not used to change the type.
>
> It is currently a c-style cast.
> Attributes is built over push_back(), so the only way to cleanly make
> it cons
On 02/08/2014 04:34 AM, Amos Jeffries wrote:
>>> My understanding of the plan for runners was that it would be more
>>> appropriate for a pre-config runner which saved the state prior to
>>> config parsing and a post-config runner which sync'd them together.
>>>
>>> I see no need for a sync() meth
On 02/08/2014 03:44 PM, Kinkie wrote:
> And I don't see how to reliably get to vector[0] in pre-11 STL. Do you
> have any clue?
My understanding is that you just do &vector_object[0], but I have not
tested that.
Cheers,
Alex.
On 02/07/2014 11:33 PM, Amos Jeffries wrote:
> On 8/02/2014 10:14 a.m., Alex Rousskov wrote:
>> The feature focus is to instantly provide a ready-to-use connection to a
>> cooperating cache peer, virtually at all times. This is useful when
>> connection establishment is &
On 02/07/2014 09:26 PM, Amos Jeffries wrote:
> On 8/02/2014 1:54 p.m., Alex Rousskov wrote:
>> On 02/05/2014 07:55 AM, Amos Jeffries wrote:
>>> * Kept the TcpReceiver name for now since Alex is disagreeing with
>>> callign the interface an "agent".
>>
On 02/05/2014 07:55 AM, Amos Jeffries wrote:
> Here we have the combined patch for what I have been calling part 1 -
> Comm::TcpReceiver interface, part 2 - ConnStateData object API upgrade,
> and part 3 - HttpStateData object API upgrade.
I am puzzled about the status of this work. There seems to
This email is about a couple of issues that I spotted in the big patch
that need to be addressed but probably do not have a significant effect
on the discussions about the overall change design.
On 02/05/2014 07:55 AM, Amos Jeffries wrote:
> -memcpy(space(), newContent, sz);
> +//
On 02/04/2014 12:57 PM, Kinkie wrote:
> On Sun, Feb 2, 2014 at 10:42 PM, Amos Jeffries wrote:
>> On 2014-02-03 08:06, Kinkie wrote:
>>>
>>> Hi,
>>> the attached patch (merge from lp:~squid/squid/vector-refactor) is
>>> an attempt to refactor Vector and its clients so that:
>>> - clients of Vecto
On 01/30/2014 01:37 PM, Alex Rousskov wrote:
> On 01/30/2014 12:14 PM, Kinkie wrote:
>> Ok, here's some numbers (same testing methodology as before)
>>
>> Trunk: mean RPS (CPU time)
>> 10029.11 (996.661872)
>> 9786.60 (1021.695007)
>> 10116.93 (988.3956
On 02/03/2014 03:22 PM, Alex Rousskov wrote:
> On 02/03/2014 01:55 PM, Amos Jeffries wrote:
>> FWIW; this seems to be the same issue is under discussion in squid-users
>> thread "rock store: a bug or ...?". Cc'ing Henrik Lidström and Nikolai
>> Gorchilov.
On 02/02/2014 02:42 PM, Amos Jeffries wrote:
> in src/HttpHdrRange.cc
>
> * This pattern happens several times throughout this patch:
> -while (!specs.empty())
> -delete specs.pop_back();
> +while (!specs.empty()) {
> +delete specs.back();
>
On 02/03/2014 01:55 PM, Amos Jeffries wrote:
> FWIW; this seems to be the same issue is under discussion in squid-users
> thread "rock store: a bug or ...?". Cc'ing Henrik Lidström and Nikolai
> Gorchilov.
>
> Henrik, Nokolai: if you could followup to squid-dev in future about this
> please.
>
>
Hello,
The following peerSelectDnsResults() code appears to care about IP
address cycling (using all the different cached IP addresses associated
with a single DNS name). The code reads ia->cur, increments the local ip
counter on every loop iteration, and checks for wrapping:
> // loo
On 01/30/2014 03:35 PM, Amos Jeffries wrote:
> P4-b: Shall we skip the arguing and go straight to ACL driven in that
> format? I think it may be faster to simply write up a patch for ACLs
> with a default "allow all" and simply allow/deny action choice than to
> continue discussions around the on/
On 01/29/2014 09:27 PM, Amos Jeffries wrote:
> On 30/01/2014 2:29 p.m., Alex Rousskov wrote:
>> > Ability to run two concurrent instances using the same configuration
>> > file does not sound like a reasonable goal/requirement to me. Has
>> > anybody even asked for t
On 01/29/2014 09:01 PM, Amos Jeffries wrote:
> On 30/01/2014 2:06 p.m., Alex Rousskov wrote:
>> On 01/29/2014 03:44 PM, Amos Jeffries wrote:
>>> On 2014-01-30 06:55, Alex Rousskov wrote:
>>>> The kid executable (e.g., disker, coordinator, worker, etc.) path is
>&
On 01/30/2014 12:14 PM, Kinkie wrote:
> Ok, here's some numbers (same testing methodology as before)
>
> Trunk: mean RPS (CPU time)
> 10029.11 (996.661872)
> 9786.60 (1021.695007)
> 10116.93 (988.395665)
> 9958.71 (1004.039956)
>
> stdvector: mean RPS (CPUtime)
> 9732.57 (1027.426563)
> 10388.38
[I may have figured out why we could not make progress before, and we
may be finally converging on a solution. P4 at the bottom. ]
On 01/29/2014 08:51 PM, Amos Jeffries wrote:
> On 30/01/2014 1:44 p.m., Alex Rousskov wrote:
>>>> P1: ignore "ftp_epsv off" for IPv6 serve
On 01/29/2014 04:03 PM, Amos Jeffries wrote:
> On 2014-01-30 06:55, Alex Rousskov wrote:
>> On 01/29/2014 02:00 AM, Amos Jeffries wrote:
>>
>>> Lets assume for a minute or ten that we all agree with this design and
>>> start implementing it ...
>>>
>&
On 01/29/2014 03:44 PM, Amos Jeffries wrote:
> On 2014-01-30 06:55, Alex Rousskov wrote:
>> The kid executable (e.g., disker, coordinator, worker, etc.) path is
>> already covered by the current Squid executable path.
> What?
> Executable path as I understand it is in .../sb
On 01/29/2014 03:19 PM, Amos Jeffries wrote:
> [if you don't want the point-by-point skip to the end ]
I skipped discussion of other use cases. I want to focus on my simple
use case before considering others (and no, I did not say my case is
more important than others; just that I want to focus on
On 01/29/2014 02:32 PM, Kinkie wrote:
> On Wed, Jan 29, 2014 at 7:52 PM, Alex Rousskov wrote:
>> On 01/29/2014 07:08 AM, Kinkie wrote:
> (in a trunk checkout)
> bzr diff -r lp:/squid/squid/vector-to-stdvector
>
> The resulting diff is reversed, but that should be easy enou
On 01/29/2014 07:08 AM, Kinkie wrote:
>Amos has asked me over IRC to investigate any performance
> differences between Vector and std::vector. To do that, I've
> implemented astd::vector-based implementation of Vector
> (feature-branch: lp:~squid/squid/vector-to-stdvector).
Does Launchpad off
On 01/29/2014 02:00 AM, Amos Jeffries wrote:
> Lets assume for a minute or ten that we all agree with this design and
> start implementing it ...
>
> A default Squid will need the following new directives:
>
> collapsed_forwarding_metadata_shm
> collapsed_forwarding_queues_shm
> collapsed_
On 01/28/2014 11:11 PM, Kinkie wrote:
> IMO it is right for paths to be absolutely configureable in squid.conf.
> At the same time, I see nothing wrong with having a concept of an
> "instance name" which could default to "squid" or to "" when not
> provided.
The above matches the approach I am ro
On 01/29/2014 12:30 AM, Amos Jeffries wrote:
> "off" should never be abused to mean half-off.
The problem here is that the directive itself was misnamed IMO.
>>> It is named correctly for its scope
>> OK, then its scope is wrong.
> The scope is right.
For IPv4, it is right. For IPv6, it
On 01/28/2014 09:29 PM, Amos Jeffries wrote:
> On 29/01/2014 9:24 a.m., Alex Rousskov wrote:
>> On 01/25/2014 06:05 PM, Amos Jeffries wrote:
>>> "off" should never be abused to mean half-off.
>> The problem here is that the directive itself was mi
I wrote a detailed point-by-point response, but decided to delete it. I
doubt it would bring us closer to an agreement because we are still
looking at the problem from two different angles:
On 01/28/2014 05:29 PM, Amos Jeffries wrote:
> Lets look at the BNF:
>
> FOO.pid = chroot pid_filename
>
On 01/28/2014 02:52 PM, e...@frap.net wrote:
> On Tue, Jan 28, 2014 at 01:03:24PM -0700, Alex Rousskov wrote:
>> Should this directive implementation be adjusted to also work for
>> disabling TCP keepalive for outbound connections if the admin wants to
>> overwrite a system
On 01/26/2014 06:58 PM, Amos Jeffries wrote:
> I am looking at making a few more items in the startup and shutdown
> sequences of Squid into Runners.
>
> I cannot quite see how to create dependencies such that Runner A does
> not occur until after Runner B has completed. Such as allocate cache
> h
On 01/25/2014 06:05 PM, Amos Jeffries wrote:
> On 25/01/2014 9:27 a.m., Alex Rousskov wrote:
>
>> I propose to limit squid.conf "ftp_epsv off" prohibition to IPv4 FTP
>> servers.
...
>> Do you think it would be OK to allow the use of EPSV commands with IPv6
On 01/28/2014 11:14 AM, e...@frap.net wrote:
> Below I include a patch to enable configurable SO_KEEPALIVE on outbound
> connections from Squid.
> +NAME: tcp_keepalive
If the new directive is specific to outbound connections, should it be
renamed to reflect that fact? How about tcp_outgoing_kee
On 01/21/2014 01:23 AM, Amos Jeffries wrote:
> On 14/01/2014 3:31 p.m., Alex Rousskov wrote:
>> On 01/07/2014 08:35 AM, Alex Rousskov wrote:
>>
>>> 2) [Add cbdata debugging to] find which object stores the invalid cbdata
>>> pointer. Then find how that invalid poin
On 01/28/2014 11:56 AM, Henrik Nordström wrote:
> tis 2014-01-28 klockan 11:25 -0700 skrev Alex Rousskov:
>
>> Why do we need a command line option to specify a service name? Can the
>> service name be configured via squid.conf? The squid.conf location is
>> already confi
On 11/01/2013 07:11 AM, Amos Jeffries wrote:
> -n - Windows service name
>
> The Windows build of Squid requires a -n option to point at the
> particular named service which is running in the background. Which
> defaults to the name "squid" when omitted.
Why do we need a command line option to s
On 01/27/2014 06:44 AM, Amos Jeffries wrote:
> On 27/01/2014 8:18 a.m., Henrik Nordström wrote:
>> How do using a service name for these differ from having a squid.conf
>> set the name (possibly using the same service name as a macro
>> expansion)?
> squid.conf lines effects differ based on all th
On 01/26/2014 08:06 PM, Amos Jeffries wrote:
>
> revno: 13247
> committer: Amos Jeffries
> branch nick: trunk
> timestamp: Sun 2014-01-26 20:06:15 -0700
> message:
> Add ${service_name} macro to squid.conf processing
>
> This allo
On 01/24/2014 01:11 PM, Henrik Nordström wrote:
> fre 2014-01-24 klockan 08:57 -0700 skrev Alex Rousskov:
>
>> Please note that since Windows admins want a service name even if they
>> do not run multiple single-build instances on the same box, setting that
>> service
Hello,
I propose to limit squid.conf "ftp_epsv off" prohibition to IPv4 FTP
servers.
Setting ftp_epsv to "off" is often necessary to correctly handle
real-world cases where an IPv4 FTP server correctly responds to an EPSV
command but is located behind a firewall that does not understand EPSV
On 01/23/2014 02:34 AM, Amos Jeffries wrote:
> On 22/01/2014 10:32 p.m., Henrik Nordström wrote:
>> Any design that tries to make application level code (i.e. http/ftp
>> protocol handlers etc) needing to be aware of TcpReceiver/Sender is
>> plain wrong imho.
> Yes. I was loosely thinking of compl
On 01/22/2014 06:16 PM, Amos Jeffries wrote:
> On 2014-01-22 18:45, Alex Rousskov wrote:
>> The correct design depends
>> on what our clients and servers need. I am seriously worried that you
>> are too focused on one server now (client_side_*cc) and once you start
>>
On 01/23/2014 06:23 AM, Amos Jeffries wrote:
>>> +if (size < 0) {
>>> +if (!ignoreErrno(xerrno)) {
>>> +debugs(5, 2, tcp << " read failure: " << xstrerr(xerrno));
>>> +return true;
>>> +} else if (!inBuf.hasContent()) {
>>> +debugs(5, 2, tcp <
On 01/23/2014 09:00 PM, Amos Jeffries wrote:
> The opening up of -n is now done in trunk. Anything which needs to be
> unique for the instance/service should begin to make use of the global
> char* service_name as part of its uniqueness.
The above scope definition would apply to things like the d
On 01/07/2014 02:52 AM, Amos Jeffries wrote:
> Updated patch attaced for audit.
>
> This one includes all the currently known bits for server-side delay
> pools so no audit omissions this time around.
>
> On 4/01/2014 8:16 a.m., Alex Rousskov wrote:
>> On 12/03/2013 10:05
On 01/21/2014 03:54 PM, Amos Jeffries wrote:
> [ On a side note shall we make a proper effort to fix that confusion by
> deprecating our use of the terms and call bits client or server by
> functionality? it would be as easy to describe these area-based parts as
> client-facing or server-facing ar
[ A specific revised proposal is at the end of this email, after the
discussion. ]
On 01/20/2014 03:30 PM, Amos Jeffries wrote:
> On 2014-01-21 07:45, Alex Rousskov wrote:
>> I propose the following arrangement for the official submission:
>>
>> src/out/FtpServer.* # c
On 01/20/2014 02:28 PM, Amos Jeffries wrote:
> On 2014-01-21 08:05, Alex Rousskov wrote:
>> On 01/20/2014 08:15 AM, Kinkie wrote:
>>
>>> the attached patch is an attempt (build-tested) to rely more on
>>> nullptr in place of NULL.
>>> It takes from th
On 01/20/2014 08:15 AM, Kinkie wrote:
> the attached patch is an attempt (build-tested) to rely more on
> nullptr in place of NULL.
> It takes from the current implementation, it is just a bit more
> forceful in using nullptr if available.
Hi Kinkie,
You forgot to mention *why* do we want
Hello,
FTP gateway[1] code[2] work well, and we are polishing it for the
official submission. The biggest change we need to make is to rearrange
where the new code lives in Squid src directory. In this email, I am
proposing how to structure that new code, but I start with a little bit
of a bac
On 01/07/2014 08:35 AM, Alex Rousskov wrote:
> 2) [Add cbdata debugging to] find which object stores the invalid cbdata
> pointer. Then find how that invalid pointer gets to that object.
I think it happens here:
>> #8 0x0834f190 in CommCbMemFunT (aMeth=
>> (void
On 01/07/2014 02:40 AM, Amos Jeffries wrote:
> For background:
> CBDATA uses an external lock counting and pointer management structure
> to perform auto_ptr/unique_ptr semantics on objects. If the objects
> "this" pointer does not match a magic binary pattern in the CBDATA
> object (cookie) for t
On 12/10/2013 05:24 PM, Alex Rousskov wrote:
> On 12/01/2013 05:43 PM, Alex Rousskov wrote:
>
>> The attached patch destroys ACLs in the reverse order of creation to
>> avoid destruction segfaults during reconfiguration.
>
>> Done as trunk r13165.
>
>
> S
On 12/03/2013 10:05 PM, Amos Jeffries wrote:
> This patch abstracts the TCP socket operations out of existing
> client-side code into a class which can be re-used for any TCP socket code.
> +namespace Comm {
> +
> +class TcpReceiver : virtual public AsyncJob
> +{
> +public:
Missing class descrip
On 01/03/2014 05:28 AM, Amos Jeffries wrote:
>>> 1) avoid the current design of 2-pass parsing: a) generic-parse just to
>>> determine it is a request-line, then b) re-parse with HttpRequest to get
>>> the fields already found by HttpParser.
>> I do not think we need two passes. The caller knows
On 01/02/2014 06:45 AM, Amos Jeffries wrote:
>>> Http::Http1ParserPointer
>>
>> The proposed naming approach results in awkward names with too many
>> "HTTP"s in them. I suggest a different arrangement:
>>
>> * namespace Http // stuff common to HTTP/1 and HTTP/2 handling
>> * namespace Http::O
On 01/01/2014 05:15 AM, Amos Jeffries wrote:
> This patch renames the HttpParser class as Http1Parser (to differentiate
> from the future planned Http2Parser) and moves it into the Http namespace.
...
> Also, the HttpRequestMethod class is moved into the Http namespace and
> library to reduce depen
On 01/01/2014 07:45 AM, Francesco Chemolli wrote:
>
>> +1. IMHO, if nobody else wants to take a stab at a full audit I think
>> you should just merge this and we fix the bugs as found.
>
> I'm with Amos on this.
> Merging will also give coverity a go at it, so +1 from me as well.
Merged as trunk
On 12/30/2013 03:21 AM, Kinkie wrote:
> we have been talking about mandating c++11 some time in the next few months.
The "next few months" timeframe is not realistic IMO: There is
relatively little for Squid to gain from that requirement (without a lot
more work on our part) and there is a signif
On 12/18/2013 04:16 AM, Amos Jeffries wrote:
> On 16/10/2013 4:36 a.m., Alex Rousskov wrote:
>>
>> Going forward, I think we need to decide:
>>
>> A) Whether altering the existing "cache" directive semantics is
>> desirable. If it is a good idea, we
On 11/21/2013 01:10 AM, Amos Jeffries wrote:
> On 16/10/2013 5:13 a.m., Alex Rousskov wrote:
>> On 10/14/2013 09:28 PM, Amos Jeffries wrote:
>>>
>>> I think store_miss and send_hit are the best out of those above.
>>>
>>> The naming of HIT directive
On 12/17/2013 12:20 PM, Francesco Chemolli wrote:
>>> >> +bool operator[](unsigned char c) const {return
>>> >> chars_[static_cast(c)] == 1;}
>> >
>> > I would remove the " == 1" part to make the code simpler, avoid
>> > repeating magic constants, make it consistent with isNonZero() if that
>
round of reviews as far as I am concerned.
Thank you,
Alex.
> On Tue, Dec 17, 2013 at 6:04 PM, Kinkie wrote:
>> On Tue, Dec 17, 2013 at 6:06 AM, Alex Rousskov
>> wrote:
>>> On 12/16/2013 03:36 PM, Alex Rousskov wrote:
>>>>> Rewrite the += operator loo
On 12/17/2013 03:12 AM, Kinkie wrote:
>>> The choice to make the vector size fixed does have some sense.
>>> std::vector::operator[] doesn't resize. If we want to make
>>> variable-size vectors, then add() becomes heavy because it must
>>> reserve() to resize chars_ if the vector is not big enough,
On 12/16/2013 03:36 PM, Alex Rousskov wrote:
>> Rewrite the += operator loop to simply
>> this->add() every character in the src set. Use std::for_each or another
>> for that if possible.
> I think the above is still valid though.
but I cannot find a suitable algorit
On 12/16/2013 01:06 PM, Marcus Kool wrote:
>
>
> On 12/16/2013 01:46 PM, Alex Rousskov wrote:
>> On 12/14/2013 06:28 AM, Amos Jeffries wrote:
>>> On 14/12/2013 6:59 a.m., Marcus Kool wrote:
>>>> all,
>>>>
>>>> as discussed in a pre
On 12/16/2013 02:59 PM, Kinkie wrote:
> On Mon, Dec 16, 2013 at 5:40 PM, Alex Rousskov wrote:
>> On 12/15/2013 04:54 AM, Kinkie wrote:
>>> attached patch is from branch lp:~squid/squid/characterset/
>>> +/// add a given char to the character set. c must be >=
On 12/15/2013 04:54 AM, Kinkie wrote:
> attached patch is from branch lp:~squid/squid/characterset/
> +std::vector chars_; //std::vector is optimized
According to STL documentation for std::vector specialization:
> These changes provide a quirky interface to this specialization and
> fav
On 12/14/2013 06:28 AM, Amos Jeffries wrote:
> On 14/12/2013 6:59 a.m., Marcus Kool wrote:
>> all,
>>
>> as discussed in a previous thread, the URL rewriter protocol of Squid
>> 3.4 is different than with previous versions of Squid.
>> Despite Amos' belief, I found out yesterday that there is no ba
On 12/11/2013 11:15 AM, Kinkie wrote:
>>> CharacterSet(const char * const c, size_t len)
>>
>> You do not want the len argument. These character sets will be nearly
>> always initialized once, from constant hard-coded c-strings.
>> For esoteric cases, I would add an add(const char c) method to ad
On 12/01/2013 05:43 PM, Alex Rousskov wrote:
> The attached patch destroys ACLs in the reverse order of creation to
> avoid destruction segfaults during reconfiguration.
> Done as trunk r13165.
Sorry, that was not enough. I somehow missed an obvious use case that
the committed fix
On 12/09/2013 04:13 PM, Amos Jeffries wrote:
> Two requests for additional scope:
> * can we place this is a separate src/parse/ library please?
> - we have other generic parse code the deserves to all be bundled up
> together instead of spread out. Might as well start that collection
> process
On 12/09/2013 10:46 PM, Francesco Chemolli wrote:
> My suggestion is to have CharacterSet be a SBuf and
> rely on them, at least for now. In any case having them be a SBuf
> promotes better interface decoupling and abstraction.
CharacterSet is a "set of characters", which is semantically very
dif
Hello,
The promised Tokenizer API proposal is attached. Compared to earlier
proposals, this interface is simplified by focusing on finding tokens
(requires knowledge of allowed and prohibited character sets), not
parsing (requires knowledge of input syntax) and by acknowledging that
real parsi
On 12/09/2013 12:07 AM, Saifuddin Rangwala wrote:
> I am interested in getting the collapsed_forwarding feature
> in latest squid version.
>
> I am more than happy to see if I can do the porting myself and contribute.
Thank you very much for your kind offer. To start with, please test
whe
On 12/05/2013 01:13 PM, Goran Slavić wrote:
>> Alex: Please note that Squid already supports a primitive form of ICAP load
>> balancing using a combination of "adaptation_access" and "random" ACL.
>> It is possible to balance accesses to ICAP services by using appropriate
>> adaptation_access matc
201 - 300 of 2666 matches
Mail list logo
