> 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 _______________________________________________ Ur mailing list [email protected] http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
