On 10/29/13 11:43 PM, Ben Kloosterman wrote:
What i think hasnt been discussed ( though it has previously) is how
much of a penalty segmented stacks represent and what it could be ..
No, we tried all sorts of optimizations. Look in the history at the
scheduler code. That path was heavily opti
src/librustc/middle/trans/callee.rs line 614 says:
In particular, for lang items, it is invoked with a dest of
None, and
Did we lose the comment or was it always an incomplete comment?
And what (in particular) is about lang items?
___
Rust-dev mailing l
I really like the idea of a task being a sandbox (if pure/no-unsafe Rust).
It seems (relatively) easy for a task to keep count of the number of bytes
it allocated (or the number of blocks), both heap-allocated and
stack-allocated blocks could be meshed together there (after all, both
consume memor
If I may suggest, rather than blocking the sender in case the channel is
full, I suggest simply returning an error (or raising a condition)
immediately.
This is both extremely simple (for the channel implementer) and heavily
customizable (for the user).
It seems certainly much easier than provide
On Wed, Oct 30, 2013 at 05:02:24PM +, Sanghyeon Seo wrote:
> src/librustc/middle/trans/callee.rs line 614 says:
>
> In particular, for lang items, it is invoked with a dest of
> None, and
>
> Did we lose the comment or was it always an incomplete comment?
> And what (in particular) is about l
On Wed, Oct 30, 2013 at 3:17 PM, Niko Matsakis wrote:
> But I guess it is a legitimate question: to what extent should we
> permit safe rust code to bring a system to its knees? We can't truly
> execute untrusted code, since it could invoke native things or include
> unsafe blocks, but it'd be ni
On Thu, Oct 31, 2013 at 12:12 PM, Robert O'Callahan wrote:
> Since tasks don't share heaps, bounding their memory usage seems
> tractable; it becomes an accounting problem. Instead of using explicit
> counters I suggest following the lead of Gecko's MemShrink project and
> building infrastructure
On 10/30/13 4:12 PM, Robert O'Callahan wrote:
Since tasks don't share heaps, bounding their memory usage seems
tractable; it becomes an accounting problem. Instead of using explicit
counters I suggest following the lead of Gecko's MemShrink project and
building infrastructure to compute the memor
On 10/30/13 4:16 PM, Patrick Walton wrote:
We don't have precise stack maps, though
I should add that this is an LLVM problem, not a language problem.
Although it's a big LLVM problem that is a lot of work to fix. Maybe
some of Apple's changes will help here.
(GCC has the same problem, by t
On Thu, Oct 31, 2013 at 12:21 PM, Patrick Walton wrote:
> On 10/30/13 4:16 PM, Patrick Walton wrote:
>
>> We don't have precise stack maps, though
>>
>
> I should add that this is an LLVM problem, not a language problem.
> Although it's a big LLVM problem that is a lot of work to fix. Maybe some
>
On Thu, Oct 31, 2013 at 12:16 PM, Patrick Walton wrote:
> On 10/30/13 4:12 PM, Robert O'Callahan wrote:
>
>> Since tasks don't share heaps, bounding their memory usage seems
>> tractable; it becomes an accounting problem. Instead of using explicit
>> counters I suggest following the lead of Gecko'
On 10/30/13 4:31 PM, Robert O'Callahan wrote:
RWarcs are worse. However, tasks that share a RWarc can't generally fail
independently, I assume. So one possibility is to group tasks into units
of failure, require that RWarcs can only be shared within such units,
and account for memory usage at fai
On Mon, Oct 28, 2013 at 10:23 PM, Corey Richardson wrote:
> I've written up more thoughts on stack safety at
> http://cmr.github.io/blog/2013/10/28/more-on-stack-safety/. If no one
> objects to it (meeting tomorrow!) or has any better ideas, I'll start
> implementing it.
>
Consider this: *if* yo
It's not a problem to offer non-blocking functions on both the send and
receive sides, in addition to the blocking ones. It's up to callers to
choose what's right for their application, but at the same time, they
shouldn't have to reinvent the wheel. The reason it's not in there yet is
that riskier
14 matches
Mail list logo
