On Sun, Jan 26, 2014 at 1:26 PM, Matthieu Monrocq <
matthieu.monr...@gmail.com> wrote:
>
>
>
> On Sun, Jan 26, 2014 at 3:31 AM, Brian Anderson <bander...@mozilla.com>wrote:
>
>> On 01/25/2014 08:58 AM, Bill Myers wrote:
>>
>>> Stack management for green tasks has been based in the past first on
>>> segmented stacks and then on standard large stacks.
>>>
>>> However, I just realized that there is a third alternative which might
>>> well be better than both of those.
>>>
>>> The idea is very simple: a green task would run on a large stack like
>>> now, but when it is descheduled, a memory buffer of the size of its used
>>> stack space is allocated, and its stack data is copied there; when it is
>>> rescheduled, the stack data is copied back to the original address.
>>>
>>
>> That's a really clever idea. There are though a number of situations
>> where we unsafely read from or write into other task's stacks that would
>> need to be considered carefully.
>>
>>
> Would it be possible to statically eliminate this risk by preventing the
> promotion of such affected tasks as greenlets ? Or is there today too many
> ways to read into a greenlet stack ?
>
We *already* statically prevent tasks from reading/writing each others'
stacks, the issue here is code which uses `unsafe { }` and does it anyways,
based on particular assumptions about how stacks are implemented which
would no longer be valid. The solution would be to (considering it
carefully) fix this unsafe code to no longer rely on these assumptions.
>
> -- Matthieu
>
>
>
>>
>> _______________________________________________
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
