Hi,
is there a reason that mtn log individual-file has such a huge
performance penalty? It is a pain to use currently:
+ time mtn log
4,93 real 4,15 user 0,16 sys
+ time mtn log src/com/msc/sdm/application/SdmVersion.java
349,39 real 258,93
On Sun, Jul 09, 2006 at 12:10:42PM -0700, Nathaniel Smith wrote:
Just noticed this project:
http://aleph0.info/apso/
Early stages, but might interest some people here.
Er... That page is terribly outdated. The project has gone through many
changes after I set up the page.
And I'm curious to
Hi all,
Currently, the automation stdio interface emits all data in chunks that do not
exceed 1024 byte in size. This value was initially choosen somewhat randomly,
but seems to be way too low.
Frontends like ViewMTN, Lara, Guitone, or TracMonotone make heavy use of the
automation interface
Hi Thomas =)
[...]
So are there any objections against setting constants::automate_stdio_size to,
say, 1MB? Is there anyone('s application) depending on smaller chunks? Should
we increase the automate format version number?
As long as this chunk size is still reported by the chunk size
On Monday 10 July 2006 13:59, Thomas Keller wrote:
As long as this chunk size is still reported by the chunk size part of
stdio's output (cmdNo:err:[l|m]:chunkSize:) I have no problems
with tweaking this value. I depend on a correct value there, nothing more.
Sure, this won't be changed.
-
Thomas Moschny [EMAIL PROTECTED] writes:
[...]
So are there any objections against setting
constants::automate_stdio_size to, say, 1MB? Is there anyone('s
application) depending on smaller chunks? Should we increase the
automate format version number?
How about makeing the chunk size
Georg-W. Koltermann [EMAIL PROTECTED] writes:
is there a reason that mtn log individual-file has such a huge
performance penalty? It is a pain to use currently:
+ time mtn log
4,93 real 4,15 user 0,16 sys
+ time mtn log
Bruce Stephens [EMAIL PROTECTED] writes:
[...]
I'm not sure. There's a note here
http://venge.net/monotone/wiki/PerformanceWork, and it's been
discussed on the list before.
http://article.gmane.org/gmane.comp.version-control.monotone.devel/6213
gives a plausible explanation.
On Monday 10 July 2006 14:45, Bruce Stephens wrote:
How about makeing the chunk size settable using a new command (leaving
the default as it is)? Or set the default to 1M (or BUFSIZ, or
something), and then clients that would deadlock have a way to set it
to something smaller.
I'm not sure
On Monday 10 July 2006 14:56, Bruce Stephens wrote:
The note on the wiki seems unconvincing since mtn log shows which
files have been changed in each revision. OK, there's the issue of
file renaming, but (intuitively) surely that can't be *that* costly to
compute, especially since renames are
Thomas Moschny wrote
After thinking a while about it, it is no longer clear to me, why there is a
need for chunked output *at all* ...
The reading side of a pipe can always read the data in arbitrarily (and
independently of the sender) sized packets, even when using synchronous I/O,
by
On Mon, 2006-07-10 at 16:09 +0200, Thomas Keller wrote:
Thomas Moschny wrote
After thinking a while about it, it is no longer clear to me, why there is
a
need for chunked output *at all* ...
The reading side of a pipe can always read the data in arbitrarily (and
independently of
We can't use an in-stream EOF token, because the stream should be
binary-safe. So this means prefixing each data chunk with the size of
that chunk. A chunk is output when it reaches the maximum size (because
having a known maximum size seems convenient), or when the stream is
flushed (my
Thomas Keller [EMAIL PROTECTED] writes:
Well, the EOF token wouldn't really have to be '\0', just something a
parser could distinguish from the normal output flow. F.e. in emails
the header is separated from the body by double newlines \n\n. If
basic_io would become standard for all output of
On Mon, 2006-07-10 at 18:50 +0200, Thomas Keller wrote:
We can't use an in-stream EOF token, because the stream should be
binary-safe. So this means prefixing each data chunk with the size of
that chunk. A chunk is output when it reaches the maximum size (because
having a known maximum
[EMAIL PROTECTED] writes:
From: Nathaniel Smith [EMAIL PROTECTED]
Subject: Re: [Monotone-devel] Re: Monotone-devel Digest, Vol 39, Issue
15
[ code to check that mtn process is still alive after sleep is wrong ]
I just saw the code in mtn.py that does a sleep(3) in order to wait
On Monday 10 July 2006 17:48 Timothy Brownawell wrote:
There are changes to inventory in the works, that would require changing
the interface version anyway, perhaps we should increase the chunk size
at the same time we land that?
Yes. And I think we should change the docs (for the new
On Mon, Jul 10, 2006 at 08:17:36PM +0200, Thomas Moschny wrote:
On Monday 10 July 2006 17:48 Timothy Brownawell wrote:
There are changes to inventory in the works, that would require changing
the interface version anyway, perhaps we should increase the chunk size
at the same time we land
On Mon, 2006-07-10 at 13:29 -0700, Rob Schoening wrote:
but my question is really: how vulnerable is mtn serve today to DoS
and buffer overrun type exploits?
DoS: It'd be fairly simple to make monotone eat all your CPU (or on an
SMP box, as much CPU as a single-threaded program can eat). If
Wrong reply button...
-- Forwarded message --
From: Nuno Lucas [EMAIL PROTECTED]
Date: Jul 10, 2006 10:08 PM
Subject: Re: [Monotone-devel] encrypted monotone (and digression on
To: Rob Schoening [EMAIL PROTECTED]
On 7/10/06, Rob Schoening [EMAIL PROTECTED] wrote:
I have a
On 7/10/06, Nathaniel Smith [EMAIL PROTECTED] wrote:
On Mon, Jul 10, 2006 at 08:17:36PM +0200, Thomas Moschny wrote:
The point of having an upper-limit is to put an upper bound on how
much memory monotone has to use. 1M seems a bit large for this
purpose, and I'm astonished if you actually have
Rob Schoening wrote:
I have a somewhat unrelated question that touches on a more fundamental
security issue:
what is the relative security risk of running netsync on a public port
assuming it's running as a non privileged user? how much of a
vulnerability is it for the host that's serving
22 matches
Mail list logo
