> Anyway, I still like the idea, but I wonder if now right after the
> hackathon is the right time. But please continue experimenting with
> this during my vacation ;-) Changing the error message would be a good
> thing, to distinguish the various calls to munmap.
Timing is bad. We need to fix t
On Sat, Jul 12, 2014 at 01:10:38PM -0400, Ted Unangst wrote:
> On Fri, Jul 11, 2014 at 08:11, Ted Unangst wrote:
>
> >> I also think there's one simple case that can be added: the MMAP call
> >> at the bottom of map().
>
> On further inspection, I think this needed a slight reordering to be
> sa
On Fri, Jul 11, 2014 at 08:11, Ted Unangst wrote:
>> I also think there's one simple case that can be added: the MMAP call
>> at the bottom of map().
On further inspection, I think this needed a slight reordering to be
safe.
I have also been seeing random munmap errors running jruby:
java(3451)
On Fri, Jul 11, 2014 at 13:56, Otto Moerbeek wrote:
> On Fri, Jul 11, 2014 at 06:28:04AM -0400, Ted Unangst wrote:
>
>> We don't need to hold the malloc lock when making syscalls like mmap
>> and munmap if we're just a little careful about the order of
>> operations. This will allow other threads
On Fri, Jul 11, 2014 at 06:28:04AM -0400, Ted Unangst wrote:
> We don't need to hold the malloc lock when making syscalls like mmap
> and munmap if we're just a little careful about the order of
> operations. This will allow other threads to concurrently allocate
> perhaps smaller chunks while the
We don't need to hold the malloc lock when making syscalls like mmap
and munmap if we're just a little careful about the order of
operations. This will allow other threads to concurrently allocate
perhaps smaller chunks while the first thread is in the kernel.
This makes a huge difference in a sim
