MemoryView provides the features to share multidimensional homogeneous arrays of
fixed-size element on memory among extension libraries.
## Disclaimer
* This feature is still experimental. The specification described here can be changed in the future.
* This document is under construction. Please refer the master branch of ruby for the latest version of this document.
## Overview
We sometimes deal with certain kinds of objects that have arrays of the same typed fixed-size elements on a contiguous memory area as its internal representation.
Numo::NArray in numo-narray and Magick::Image in rmagick are typical examples of such objects.
MemoryView plays the role of the hub to share the internal data of such objects without copy among such libraries.
Copy-less sharing of data is very important in some field such as data analysis, machine learning, and image processing. In these field, people need to handle large amount of on-memory data with several libraries. If we are forced to copy to exchange large data among libraries, a large amount of the data processing time must be occupied by copying data. You can avoid such wasting time by using MemoryView.
MemoryView has two categories of APIs:
1. Producer API
Classes can register own MemoryView entry which allows objects of that classes to expose their MemoryView
2. Consumer API
Consumer API allows us to obtain and manage the MemoryView of an object
## MemoryView structure
A MemoryView structure, `rb_memory_view_t`, is used for exporting objects' MemoryView.
This structure contains the reference of the object, which is the owner of the MemoryView, the pointer to the head of exported memory, and the metadata that describes the structure of the memory. The metadata can describe multidimensional arrays with strides.
### The member of MemoryView structure
The MemoryView structure consists of the following members.
-`VALUE obj`
The reference to the original object that has the memory exported via the MemoryView.
RubyVM manages the reference count of the MemoryView-exported objects to guard them from the garbage collection. The consumers do not have to struggle to guard this object from GC.
The private data that MemoryView provider uses internally.
This can be `NULL` when any private data is unnecessary.
## MemoryView APIs
### For consumers
-`bool rb_memory_view_available_p(VALUE obj)`
Return `true` if `obj` supports to export a MemoryView. Return `false` otherwise.
If this function returns `true`, it doesn't mean the function `rb_memory_view_get` will succeed.
-`bool rb_memory_view_get(VALUE obj, rb_memory_view_t *view, int flags)`
If the given `obj` supports to export a MemoryView that conforms the given `flags`, this function fills `view` by the information of the MemoryView and returns `true`. In this case, the reference count of `obj` is increased.
If the given combination of `obj` and `flags` cannot export a MemoryView, this function returns `false`. The content of `view` is not touched in this case.
The exported MemoryView must be released by `rb_memory_view_release` when the MemoryView is no longer needed.