[Bug 691299] API: GstFileMemAllocator - an allocator that uses disk storage to provide memory space

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=691299
  GStreamer | gst-plugins-base | git

--- Comment #11 from Krzysztof Konopko <krzysztof.konopko at gmail.com> 2013-07-30 22:20:20 UTC ---
(In reply to comment #9)
My gut feeling is that what you suggest makes a lot sense but please see my
questions below.

> I think there should be a GstMMapMemory that is independent of this allocator
> and only has an fd and the offset inside it, and the mapping functions would
> then call mmap() or whatever is required.

As I understand data redundancy is acceptable here.  I mean GstMMapMemory (or
GstMappedFileMemory as I renamed it to) inherits from GstMemory which already
contains a reference to the allocator and GstMMapAllocator (or
GstMappedFileAllocator as I renamed it to) has got the file descriptor.  My
understanding is that any memory is always somehow related to and dependent on
its allocator.  Is your intention to decouple things here?

> This very specific allocator here

Ie. which one as opposed to GstMMapAllocator?

> would be used to implement a special version of the GstMMapMemory, but there
> would also be a GstMMapAllocator that just provides the default functions for
> handling mmap'd memory.

Does it mean that the implementation of all of these would live in the same
place (file)?  How would GstMMapMemory be reused/shared after making it
independent of its allocator?

BTW, I renamed classes to GstMappedFile* as IMHO this is more generic as
opposed to implementation specific MMap (what about Windows folks?).

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.