On Mar 20, 5:59 pm, dormando wrote:
> iirc we were looking at using an option like that to pass startup
> parameters into the storage engine interface. would that be the -o option,
> then memcached itself takes normal parameters? Or would we have two
> separate "long format" parsers in the end?
> -o isn't taken yet, but that could be good. There are a few other
> hard-coded values I've found in there that might be interesting to
> adjust on a really rare base (e.g. how deep to walk the LRU when
> looking for something eligible to evict).
>
> I don't know that it's *urgent* now. I l
Sorry, been a busy day, but here is a little something that can be used.
add the -o option to the getopt() line. (note the 'o:' at the end)
> *while* ((c = getopt(argc, argv,
> "a:p:s:U:m:Mc:khirvdl:u:P:f:s:n:t:D:LR:Cb:o:")) != -1) {
>
>
Add the -o option to the switch.
> *case* 'o' :
>
I've found my old code, and its rather ugly and not very portable. So I'd
rather start from scratch. I've learnt a better way of parsing
multi-delimited strings now anyway, so I'll whip something up.
On Tue, Mar 17, 2009 at 9:23 AM, Dustin wrote:
>
>
> On Mar 16, 5:05 pm, Clint Webb wrote:
>
On Mar 16, 5:05 pm, Clint Webb wrote:
> Actually that is a good point. I hadn't thought of that. I have some
> services that I wrote a long time ago that take a -o options setting, which
> is for those odd options that are rarely used, but occassionaly needed for
> fine-tuning...
>
> so I woul
Actually that is a good point. I hadn't thought of that. I have some
services that I wrote a long time ago that take a -o options setting, which
is for those odd options that are rarely used, but occassionaly needed for
fine-tuning...
so I would have something like:
webservice -v -a 127.0.0.1
Thanks for all the feedback. I was thinking that a compile-time
option might be good to avoid eating up the precious getopt space for
things that are rarely used, but this is pretty unanimous. :)
On Mar 16, 5:38 am, Trond Norbye wrote:
> Dustin wrote:
> > Chris Goffinet removed another ma
Dustin wrote:
Chris Goffinet removed another magic number by making the TCP listen
backlog runtime configurable here:
http://github.com/lenn0x/memcached/commit/7d010a855ecccf4960fce4ffa4bd79d686130ca6
Before this change, memcached had a hard-coded backlog of 1024.
It's possible to excee
I agree that it should be a runtime option. Its not something that would
affect anything after startup. The only times I think things should be
compile time, is when it makes the server unstable, os/environment specific,
or affects performance whether it is on or off.
My $0.02 worth.
On Mon, Ma
On Mon, Mar 16, 2009 at 07:49, Dustin wrote:
>
> Does anyone have an opinion on this? My only question is whether it
> should be a compile-time option or a runtime option.
If you make it a runtime option, it'll be much easier to help people that
seem to run into it by telling them to try a sw
Chris Goffinet removed another magic number by making the TCP listen
backlog runtime configurable here:
http://github.com/lenn0x/memcached/commit/7d010a855ecccf4960fce4ffa4bd79d686130ca6
Before this change, memcached had a hard-coded backlog of 1024.
It's possible to exceed 1024 with a c
11 matches
Mail list logo
