Added https://github.com/mozilla/rust/issues/10350 then :-)
On Fri, Nov 8, 2013 at 9:00 AM, Daniel Micay wrote:
> On Fri, Nov 8, 2013 at 1:59 AM, Daniel Micay wrote:
>
>> On Fri, Nov 8, 2013 at 1:52 AM, Oren Ben-Kiki wrote:
>>
>>> How bad would it be to add another 64 bits to the "some data to
On Fri, Nov 8, 2013 at 1:59 AM, Daniel Micay wrote:
> On Fri, Nov 8, 2013 at 1:52 AM, Oren Ben-Kiki wrote:
>
>> How bad would it be to add another 64 bits to the "some data to go along
>> with it" part? I'm assuming 32 bit for file name index in some table and 32
>> bit for the line number in th
On Fri, Nov 8, 2013 at 1:52 AM, Oren Ben-Kiki wrote:
> How bad would it be to add another 64 bits to the "some data to go along
> with it" part? I'm assuming 32 bit for file name index in some table and 32
> bit for the line number in the file should be enough :-)
>
In debug builds, no problem a
How bad would it be to add another 64 bits to the "some data to go along
with it" part? I'm assuming 32 bit for file name index in some table and 32
bit for the line number in the file should be enough :-)
On Fri, Nov 8, 2013 at 8:48 AM, Daniel Micay wrote:
> On Fri, Nov 8, 2013 at 1:45 AM, Ore
On Fri, Nov 8, 2013 at 1:45 AM, Oren Ben-Kiki wrote:
> Good to know! The GDB stack traces leave something to be desired, though -
> e.g. the way it reports closures isn't really very useful (adding source
> file name and line number would be really good there). But it is certainly
> better than n
Good to know! The GDB stack traces leave something to be desired, though -
e.g. the way it reports closures isn't really very useful (adding source
file name and line number would be really good there). But it is certainly
better than nothing. Thanks!
On Fri, Nov 8, 2013 at 8:40 AM, Corey Richard
Entirely unrelated. Do note that we have stack traces *now*, as long
as you're using gdb to get them :). Break on `rust_begin_unwind` or
"catch throw".
On Fri, Nov 8, 2013 at 1:27 AM, Oren Ben-Kiki wrote:
> Does ditching segmented stacks mean we can start getting a stack trace when
> a task `fail
Does ditching segmented stacks mean we can start getting a stack trace when
a task `fail!`s? Or is this an unrelated issue?
The lack of stack traces is extremely tedious when debugging failed
assertions...
___
Rust-dev mailing list
Rust-dev@mozilla.org
h
On Tue, Nov 5, 2013 at 4:40 PM, Brian Anderson wrote:
> On 11/04/2013 07:50 PM, Bill Myers wrote:
>
> The advantage of segmented stacks is that blocked tasks only take up as much
> memory as they actually need to store state, so that for instance a network
> server can use a task for each connecti
C# Async/Await is distinct from segmented stacks because they store the
enclosed variables as heap objects rather than on the stack; that means it
goes through the same malloc/garbage collector as any other heap objects
you create. It's purely a compiler fiction to let you write code that
'looks' l
On 11/04/2013 09:21 PM, Oren Ben-Kiki wrote:
Note that as memory becomes cheaper and larger there will be more
pressure on 64-bit OS-es to switch to large pages; the number of pages
needed to map several GBs of memory today is already getting out of
hand, causing TLB misses to become a performa
On 11/04/2013 07:50 PM, Bill Myers wrote:
The advantage of segmented stacks is that blocked tasks only take up
as much memory as they actually need to store state, so that for
instance a network server can use a task for each connection, and
still only use, say, 64 bytes per connection if that'
On 11/5/13 8:32 AM, David Piepgrass wrote:
Segmented stacks aren't the only solution though.
If the concern is many tasks that block for a long time, I imagine a
mechanism to bundle a bunch of small, dormant stacks into a single page
so that the original pages could be released to the OS.
If st
If you really need such a small memory footprint for your tasks, I am of
the opinion that it would be less error prone (whoops, accidentally used 64
bytes of stack than I should have, now I'm using twice as much memory!) to
use an async event loop, like libevent, rather than a task model. It just
d
Segmented stacks aren't the only solution though.
If the concern is many tasks that block for a long time, I imagine a
mechanism to bundle a bunch of small, dormant stacks into a single page so
that the original pages could be released to the OS.
If stacks were additionally relocatable (which req
Having memory is cheap, accessing it isn't.
On Monday, November 4, 2013, Thad Guidry wrote:
> Bill, memory is cheap.
>
>
> On Mon, Nov 4, 2013 at 9:50 PM, Bill Myers
>
> > wrote:
>
>> The advantage of segmented stacks is that blocked tasks only take up as
>> much memory as they actually need to
Note that as memory becomes cheaper and larger there will be more pressure
on 64-bit OS-es to switch to large pages; the number of pages needed to map
several GBs of memory today is already getting out of hand, causing TLB
misses to become a performance issue in some cases - imagine a system with
0
Bill, memory is cheap.
On Mon, Nov 4, 2013 at 9:50 PM, Bill Myers wrote:
> The advantage of segmented stacks is that blocked tasks only take up as
> much memory as they actually need to store state, so that for instance a
> network server can use a task for each connection, and still only use,
The advantage of segmented stacks is that blocked tasks only take up as much
memory as they actually need to store state, so that for instance a network
server can use a task for each connection, and still only use, say, 64 bytes
per connection if that's possible instead of the number of stack p
19 matches
Mail list logo
