[#70252] Re: [ruby-cvs:58640] nobu:r51492 (trunk): node.c: NODE_ALLOCA for ALLOCV — Eric Wong <normalperson@...>
Besides possible backwards compatibility, can we drop volatile
3 messages
2015/08/05
[#70257] [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI — ko1@...
Issue #11420 has been reported by Koichi Sasada.
11 messages
2015/08/06
[#70337] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/11
Nice. Thank you guys for looking into this.
[#70349] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/12
Btw, did you consider using flexible array to avoid extra malloc
[#70355] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Юрий Соколов <funny.falcon@...>
2015/08/12
I thought to suggest to embed hash_id_table directly into places when it is
[#70356] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— SASADA Koichi <ko1@...>
2015/08/12
On 2015/08/13 4:29, Юрий Соколов wrote:
[#70358] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/12
SASADA Koichi <ko1@atdot.net> wrote:
[#70509] [Ruby trunk - Misc #11276] [RFC] compile.c: convert to use ccan/list — ko1@...
Issue #11276 has been updated by Koichi Sasada.
3 messages
2015/08/21
[#70639] the undefined behavior of an iterator if it is modified inside of the block to which it yields — Daniel Doubrovkine <dblock@...>
(this is my first time e-mailing list list, so apologies for any misstep :)
4 messages
2015/08/31
[ruby-core:70244] Re: Force ruby to allocate a new heap page
From:
Cesar De Hoyos <cdehoyos@...>
Date:
2015-08-04 18:49:18 UTC
List:
ruby-core #70244
>Could you explain what do you want to make? We are using a C library (BOP, link here) <http://roclocality.org/2015/05/17/rubybop-introduction/> that implements OpenMP-like directives, using processes instead of threads to guarantee correctness. BOP uses forks to achieve this, so at a point (at the start of forks) we have different tasks with the exact same address space. Because of how the library is implemented, these tasks cannot modify to the same virtual address. Thus, we want the tasks to allocate a new heap page using our custom memory allocator (which replaces libc malloc calls in ruby). To force this new heap page allocation, we want to use the method in the last message, as we are trying to minimize the changes to ruby itself. I hope this is a bit more clear. I am trying to not go too much into the whole BOP library in itself, for the sake of simplicity. If you're curious/interested you can read the blog post (linked above) and/or the papers attached in there. Thanks again! -Cesar De Hoyos On Tue, Aug 4, 2015 at 1:54 PM, SASADA Koichi <ko1@atdot.net> wrote: > On 2015/08/05 0:08, Cesar De Hoyos wrote: > > process-based support for parallelization > > Could you explain what do you want to make? At least I can't understand > what do you want. So that I can't explain how to solve. > > -- > // SASADA Koichi at atdot dot net >