[Ur] missunderstanding - or serious memory handling issue?

[Marc Weber]

> If you're suggesting special memory management for Ruby objects, that 
> would probably be the best long-term solution, but it might not be much 
> better than just using malloc().
Ruby has its own gc - you have to tell the gc to that it should not
collect some vars - because you're holding references to them on C side.

I wondered about whether ur should be able to control the amount of
memory being used by a context. If you use malloc you can hold arbitrary
much data. If you used uw_malloc you knew that ur could apply a limit
and fail. I rewrote it using malloc / free. Its not worth thinking about
for those view bytes. I was also wondering whether uw_malloc should be
used for serving files etc. - probbaly not.

The next I wasn't sure about was speed: Is it worth trying to avoid some
mallocs or not. If uw_malloced data was valid until all callbacks
finished running - I could have used uw_malloc which probbaly is faster
than malloc. Worse: mallocing 2 bytes could realloc prevent from
resizing continuously triggering a retry (?)
I don't know enough about malloc implementations to make a judgment.

Because ur has special knowledge about the memory (it will no longer be
used after a run has finished) it can much better than malloc and free.

That's why it could be worth adding a uw_malloc_keep_valid_until_all_callbacks_were_called
function - or changing the semantics of the existing uw_malloc.
But then you can no longer use realloc.

I should and will stop thinking about it now.

Marc Weber