Re: VFS GetAllData() and memory allocation

Eunsoo Roh <[email protected]>
Newsgroups gmane.comp.graphics.crystalspace.devel
Message-ID <[email protected]>
> A perhaps better way would be to have an interface iDataBufferReadOnly
> that grants only ‘const’ access to the data; however, the most difficult
> aspect of this would be to have VFS return that *and* provide source
> compatibility.

If I were to introduce a safer interface, I'd name it iConstDataBuffer or something then make new methods with a different name or signature and deprecate old methods. Source compatibility would be preserved, and I think it wouldn't be an issue if I do it that way.

> The idea was to have a separate heap to reduce (main) heap fragmentation.
> Because: files are usually only used during loading and their data
> discarded after that. That means then you would have free heap blocks,
> from the files, at the start of the heap (because loading is usually the
> first thing done), with the processed level data (which is still in use)
> afterwards. However, these free heap blocks at the start are “nasty”
> because they take up virtual memory without much benefit. A separate
> heap for files prevents that as, well, file data goes to a different
> heap altogether.
> (At least that was the reasoning that led me to believe a heap for VFS
> files wasn't a bad idea.)
> However, having one heap for all filesystems isn't really necessary.
> Depending, on how many instances of objects providing file data you
> would typically have (ie filesystem implementation), you could have one
> heap per such object (if you have only few) or one heap per plugin (if
> you have many).

Now I understand. I guess I'm going to have different heaps for csVFS and NativeFS; for external plugins, it's up to individual developers, unfortunately.
Thanks for the clarification. That really helped.
touko

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

_______________________________________________
Crystal-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/crystal-develop
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.