you do compete with Go (4 kB initial stack segment) and Erlang (2.4 kB on
64 bit).
Actually, goroutines have a default stack size of 8kb since 1.2.
Also, applicable to this discussion, in 1.3 Go will be moving away from
segmented stacks to contiguous growable stacks:
On Thu, Oct 24, 2013 at 4:18 PM, Benjamin Striegel
ben.strie...@gmail.comwrote:
you do compete with Go (4 kB initial stack segment) and Erlang (2.4 kB
on 64 bit).
Actually, goroutines have a default stack size of 8kb since 1.2.
Also, applicable to this discussion, in 1.3 Go will be moving
On 10/24/13 9:12 AM, Matthieu Monrocq wrote:
On Thu, Oct 24, 2013 at 4:18 PM, Benjamin Striegel
ben.strie...@gmail.com mailto:ben.strie...@gmail.com wrote:
you do compete with Go (4 kB initial stack segment) and Erlang
(2.4 kB on 64 bit).
Actually, goroutines have a default
I am curious. Isn't the stack a very simple region? Couldn't region
inference be used to solve pointer-to-stack problems?
Or do I completely misunderstand the definition of pointer-to-the-stack?
On 10/24/13 6:12 PM, Matthieu Monrocq wrote:
This is an interesting move, however the
Yes its a simple region but region analysis is normally compile time while
this is runtime..knowing the pointer points to the stack doesnt help .
If you copy in a new stack you need to know every pointer to that stack if
you move it to a new location .. Copying GCs do this all the time but they
On 10/24/13 6:13 PM, Ben Kloosterman wrote:
Yes its a simple region but region analysis is normally compile time
while this is runtime..knowing the pointer points to the stack doesnt help .
If you copy in a new stack you need to know every pointer to that stack
if you move it to a new location
On 10/24/2013 06:16 PM, Patrick Walton wrote:
On 10/24/13 6:13 PM, Ben Kloosterman wrote:
Yes its a simple region but region analysis is normally compile time
while this is runtime..knowing the pointer points to the stack doesnt
help .
If you copy in a new stack you need to know every
Sorry, I haven't followed newrt closely. What are the missing pieces
currently?
And there's other infrastructure in Rust for supporting segmented stacks.
Like the fixed stack attribute (and all functions already marked up with
it). Like implementations of __morestack for different
What I have in mind is not nginx, but rather something like a pub-sub
service, with millions of idle connections, which don't do much most of the
time. And no, I don't want an async I/O API :-) Not if I can help it. I
am still hoping that Rust can avoid having separate sync and async I/O APIs.
On 22 October 2013 09:56, Vadim vadi...@gmail.com wrote:
What I have in mind is not nginx, but rather something like a pub-sub
service, with millions of idle connections, which don't do much most of the
time. And no, I don't want an async I/O API :-) Not if I can help it. I
am still hoping
On 10/22/2013 12:56 AM, Vadim wrote:
What I have in mind is not nginx, but rather something like a pub-sub
service, with millions of idle connections, which don't do much most
of the time. And no, I don't want an async I/O API :-) Not if I can
help it. I am still hoping that Rust can avoid
I've written a blog post about stack safety and a proposal for how I
think it should be implemented in Rust:
http://cmr.github.io/blog/2013/10/21/on-stack-safety/
Thoughts, comments? I'm going to implement this after my (ill-kept)
hiatus if there's consensus that this is a good idea.
This seems generally on the right track. A couple of thoughts:
* I can pretty much guarantee you that that simple of a static analysis to
determine stack size is going to fail on any reasonable program. I would just
leave it out. If you're feeling ambitious, you could implement it as an LLVM
On Mon, Oct 21, 2013 at 11:48 AM, Patrick Walton pwal...@mozilla.com wrote:
This seems generally on the right track. A couple of thoughts:
* I can pretty much guarantee you that that simple of a static analysis to
determine stack size is going to fail on any reasonable program. I would
just
It's great to see progress in this area! I know that this has been a
tricky topic in the past, and it would be awesome to get things sorted
out.
One thing I would keep in mind is that pretty much any strategy
(except the no safety one) involves changes in LLVM. I think we all
hope to one day use
=...];`,
rather than `#[stack_safety=segmented];`
The idea isn't to enable different implementations of __morestack, the
idea is to enable entirely different concepts of stack safety
entirely.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org
On Oct 21, 2013, at 9:11 AM, Corey Richardson co...@octayn.net wrote:
On Mon, Oct 21, 2013 at 11:48 AM, Patrick Walton pwal...@mozilla.com wrote:
This seems generally on the right track. A couple of thoughts:
* I can pretty much guarantee you that that simple of a static analysis to
On Mon, Oct 21, 2013 at 1:08 PM, Kevin Ballard ke...@sb.org wrote:
On Oct 21, 2013, at 9:11 AM, Corey Richardson co...@octayn.net wrote:
On Mon, Oct 21, 2013 at 11:48 AM, Patrick Walton pwal...@mozilla.com wrote:
This seems generally on the right track. A couple of thoughts:
* I can pretty
* Patrick Walton:
* I can pretty much guarantee you that that simple of a static
analysis to determine stack size is going to fail on any reasonable
program.
It's needed to show total correctness, and often done with tool
support in the embedded space. GCC has some support for it.
It seems to me that trying to determine max stack size is incompatible with
dynamic linking. So even if you disallow recursion, any function that calls
a function outside of its own crate is not going to be able to trust its
calculated max stack size.
The maximum stack size needs to
On 10/21/2013 07:30 AM, Corey Richardson wrote:
I've written a blog post about stack safety and a proposal for how I
think it should be implemented in Rust:
http://cmr.github.io/blog/2013/10/21/on-stack-safety/
Thoughts, comments? I'm going to implement this after my (ill-kept)
hiatus if
Nope. Guard zones, not guard page (singular!). Except in the face of
loading things from dynamic libs at runtime (which is unsafe right now
anyway), you can always determine the maximum stack frame used by a
given executable crate.
On Mon, Oct 21, 2013 at 8:37 PM, Keegan McAllister
Hi Brian,
Can you please elaborate on why segmented stacks fell out of favor? Maybe
it's been discussed among the core Rust team, but external people like me
are probably wondering why.
It seems to me that segmented stacks would be essential for async I/O and
actor-based architectures, no?
On 10/21/13 8:48 PM, Daniel Micay wrote:
Segmented stacks result in extra code being added to every function,
loss of memory locality, high overhead for calls into C and
unpredictable performance hits due to segment thrashing.
They do seem important for making the paradigm of one task per
On Tue, Oct 22, 2013 at 12:37 AM, Vadim vadi...@gmail.com wrote:
Ok, so maybe they should be disabled by default. But to eliminate them
outright would be shortsighted, IMHO. Can we leave them as an option for
people who do care about this sort of stuff?
Segmented stacks aren't actually
25 matches
Mail list logo
