read() performance - Linux.too?

[Unknown W. Brackets]

I don't think it does.  I think it has to be in one of the GC's pools 
and buckets.  I don't think you can add malloc'd memory to the GC.

I may be wrong.

Why not...

buf = new byte[size];
std.gc.removeRange(buf);

Yes, it's a bit silly removing the range immediately after adding it, 
but the point is to get it not to try to scan the memory, right?

-[Unknown]


> On Mon, 24 Jul 2006 23:04:09 -0700, Unknown W. Brackets wrote:
> 
>> Derek,
>>
>> Your question doesn't make complete sense to me, so I'm going to back up 
>> a bit.  Please forgive me if I patronize you, or fail to answer your 
>> question.
> 
> Not a problem.
>  
>> The garbage collector has "ranges" of memory it scans (as I'm completely 
>> sure you already know.)  For example, you could add an arbitrary range. 
>>   Consider:
>>
>> void* p = malloc(100);
>> std.gc.addRange(p, p + cast(ptrdiff_t) 100);
>>
>> This will cause it to scan the space between (p) and (p + 100) or 
>> pointers (roots.)  Removing a range does not mean, as far as I can see, 
>> that the memory it points to will never be freed; just that it will not 
>> be scanned.
> 
> So long as the root itself is stored somewhere that the GC can find it. I
> guess this is done via the addRoot() call and I assume that 'new'
> automatically calls this.
> 
>> I completely agree that Phobos' read() should have a removeRange() call 
>> there, unless it is decided to add such a thing to the standard library.
> 
> I just tried something like that out. In file.d I changed 
> 
>     buf = new byte[size];
> 
> to ...
> 
>     void *p = malloc(size);
>     if (p == null)
>         throw new OutOfMemoryException;
>     buf = cast(byte[])p[0..size];
> 
> 
> I assume that the " = p[x..y]" construct adds the root to the GC.
>