On 13-07-04 07:30 PM, Thad Guidry wrote:
On Windows there's a better way than DWARF or SJLJ to catch exceptions I
learned today. (I have no idea what I am talking about, but here goes
from what I read...)
Windows uses it's own exception handling mechanism known as SEH. GCC
supports SEH on
On 13-07-04 10:54 PM, james wrote:
If the segments are allocated from a selection of standard sizes, can
you not have a (hardware) thread-local pool for each size and dump to a
shared pool?
No. We should be, but we've not moved to a single page-size pool yet. I
hope to move to this design as
On 5 July 2013 09:37, Graydon Hoare gray...@mozilla.com wrote:
It's all done by comparing the stack pointer to a reserved segment register.
The growth-prologue on x64 looks like this:
I am curious, has moving stack checks to the caller been considered so
a function code can assume that it
I believe that instead of segmented stacks, the runtime should determine a
tight upper bound for stack space for the a task's function, and only allocate
a fixed stack of that size, falling back to a large C-sized stack if a bound
cannot be determined.
Such a bound can always be computed if
On Fri, Jul 5, 2013 at 4:58 PM, Bill Myers bill_my...@outlook.com wrote:
I believe that instead of segmented stacks, the runtime should determine a
tight upper bound for stack space for the a task's function, and only
allocate a fixed stack of that size, falling back to a large C-sized stack
On 05/07/2013 08:37, Graydon Hoare wrote:
I agree that it's higher than it seems it needs to be. But it will
always be unnecessary overhead on x64; it really makes no sense there.
The address space is enormous and it's all lazily committed.
I don't think you can rely on 'lazily committed'.
On Fri, Jul 5, 2013 at 5:43 PM, james ja...@mansionfamily.plus.com wrote:
On 05/07/2013 08:37, Graydon Hoare wrote:
I agree that it's higher than it seems it needs to be. But it will
always be unnecessary overhead on x64; it really makes no sense there. The
address space is enormous and it's
On Fri, Jul 5, 2013 at 6:43 PM, Thomas Daede daede...@umn.edu wrote:
On Fri, Jul 5, 2013 at 5:05 PM, Daniel Micay danielmi...@gmail.com wrote:
You can rely on it, it's the standard behaviour on Linux. The actual
consumed memory will be equal to the size of the pages that have been
touched.
1. The following code
#[deriving(Clone)]
struct V {
v : [f64, ..3]
}
fn main() {
}
gives the following error
tmp.rs:1:11: 1:16 error: mismatched types: expected `[f64, .. 3]` but found
`[f64, .. 3]` (expected vector but found -ptr)
tmp.rs:1 #[deriving(Clone)]
Is this
And an additional question.
3. What is the rationale in having both Copy and Clone? Can one
provide an exhaustive list for where one would want to use Copy
instead of Clone/DeepClone? I tried to use clone everywhere, but I
needed T : Copy + Zero to be able to write, for example,
[Zero::zero(),..
On 7/5/13 10:42 PM, Ashish Myles wrote:
And an additional question.
3. What is the rationale in having both Copy and Clone? Can one
provide an exhaustive list for where one would want to use Copy
instead of Clone/DeepClone? I tried to use clone everywhere, but I
needed T : Copy + Zero to be
11 matches
Mail list logo
