bugs/issue-cfc81e9b8875cf254ce789c16c52691206077ef8.yaml

   1 --- !ditz.rubyforge.org,2008-03-06/issue
   2 title: Remedy potential allocation bug in sample client, and address this generally (_copy_host()?).
   3 desc: |-
   4   set_host will likely assume malloc()'ed memory; other kinds of memory may cause problems with this
   5   function, such that it might be desirable to add a new function for these kinds (e.g., copy_host).
   6 type: :task
   7 component: libale
   8 release:
   9 reporter: David Hilvert <dhilvert@auricle.dyndns.org>
  10 status: :closed
  11 disposition: :fixed
  12 creation_time: 2009-03-05 21:09:51.950441 Z
  13 references: []
  14
  15 id: cfc81e9b8875cf254ce789c16c52691206077ef8
  16 log_events:
  17 - - 2009-03-05 21:09:52.759080 Z
  18   - David Hilvert <dhilvert@auricle.dyndns.org>
  19   - created
  20   - ""
  21 - - 2009-03-05 21:41:12.367785 Z
  22   - David Hilvert <dhilvert@auricle.dyndns.org>
  23   - commented
  24   - |-
  25     An alternative to copy_host that may allow non-malloc()'ed memory to be used would be something
  26     similar to set_static(), specifying that passed memory is not to be handled with malloc-related
  27     functions.  Leaving the options something like:
  28
  29     (a) copy_host
  30     (b) set_static
  31     (c) require malloc-ed memory in all cases.
  32 - - 2009-03-05 21:48:36.584663 Z
  33   - David Hilvert <dhilvert@auricle.dyndns.org>
  34   - commented
  35   - |-
  36     An elegant approach to handling this issue may be to require all allocations
  37     to occur within the library, via resize operations, and to pass allocated structures
  38     back to client code via return_*() functions.  A drawback to this approach would
  39     be eliminating the possibility of efficiently handling things like mmap-ed data,
  40     but this seems likely to be a rare case, which could probably be handled through a
  41     special, separate initialization function.
  42 - - 2009-03-05 21:57:45.799069 Z
  43   - David Hilvert <dhilvert@auricle.dyndns.org>
  44   - commented
  45   - |-
  46     In the case that return_*() is used to provide buffers for data population, note that
  47     renaming these functions to something like buffer_*() might be appropriate (since
  48     providing a buffer is then the purpose), as well as requiring that only the currently
  49     active buffer type be associated with a function result (as opposed to handling
  50     buffer_*() outside of the active type; see also {issue a779dc08f3d8a143b05f9fb028fde68d42eb28cf}).
  51 - - 2009-03-05 22:15:13.450461 Z
  52   - David Hilvert <dhilvert@auricle.dyndns.org>
  53   - commented
  54   - |-
  55     An alternative to requiring all allocations to occur within the library might be to require
  56     allocations other than CL allocations to occur within the library, allowing CL allocations to
  57     occur outside the library (or perhaps allowing both CL and file allocations to occur outside
  58     of the library).
  59 - - 2009-03-05 23:59:12.817480 Z
  60   - David Hilvert <dhilvert@auricle.dyndns.org>
  61   - commented
  62   - |-
  63     Consider that, from the client's perspective, a convenient approach would
  64     probably be to have functions:
  65
  66     set_cl
  67     set_host_dynamic
  68     set_host_static
  69     set_file_dynamic
  70     set_file_static (with offset)
  71
  72     in addition to having buffer-return functions for populating memory allocated
  73     by the library.  Note that the static/dynamic dichotomy could probably be
  74     supported via a flag stored within image instances, and that such a flag could
  75     serve to disallow resizing, as well as to disable freeing of the buffer region
  76     upon freeing of the image structure.  (Resizing could then occur via a further
  77     non-static set_* operation, or through creation of a new image instance.)
  78 - - 2009-03-06 00:20:21.764730 Z
  79   - David Hilvert <dhilvert@auricle.dyndns.org>
  80   - commented
  81   - |-
  82     Note that a significant advantage of allowing the client as many options as
  83     possible is that this, in turn, allows both the library and the client code as
  84     many optimizations as possible.  In particular, the task of populating to or
  85     from a particular type of memory or file object is localizable to the library,
  86     so that optimizations can occur there, and also (if desired) localizable to
  87     client code, so that optimizations can occur there.  Providing hints (such as
  88     information about the current buffer type) to the client code allows for more
  89     effective optimization there, in cases where client-side optimization is
  90     appropriate.
  91
  92     As a consequence of the above considerations, the static/dynamic split
  93     considered earlier would probably be desirable to implement, as might
  94     maintaining a return_* semantics allowing for returns of types other than the
  95     currently active buffer.
  96
  97     (Note, however, that this latter point is somewhat less clear than the former.
  98     In particular, there are optimizations in conversions between representations
  99     that will be more effectively implemented in client code than can be done via
 100     the return_* interface [e.g., CL memory mapping for access via the host address
 101     space].)
 102 - - 2009-03-06 01:18:57.153229 Z
 103   - David Hilvert <dhilvert@auricle.dyndns.org>
 104   - commented
 105   - |-
 106     Note that it would probably be useful to have a function predicting the type
 107     of buffer that will be used given relevant parameters (esp. dimensions).  In
 108     this way, complex relationships between different parts of a memory hierarchy
 109     could be more easily established (e.g., updating of static host memory from
 110     an OpenCL buffer).
 111 - - 2009-03-06 01:26:27.633004 Z
 112   - David Hilvert <dhilvert@auricle.dyndns.org>
 113   - commented
 114   - |-
 115     Note, obviously, that, rather than having a static flag disable resizing, a static
 116     flag could cause any resize operation to trigger creation of a dynamic memory object.
 117     In this way, resizes of static and dynamic objects could occur at any time, without
 118     any special effort from client code, and without any ill effect to the static memory.
 119 - - 2009-03-06 02:44:11.544619 Z
 120   - David Hilvert <dhilvert@auricle.dyndns.org>
 121   - commented
 122   - |-
 123     Note that it would probably be useful for any set_file_static function to take
 124     a (boolean) parameter indicating whether the file is closeable (so that the
 125     file could be closed when no longer needed, and, especially, prior to
 126     destruction of the associated image object).
 127
 128     (An analogous parameter for set_host_static is at least conceivable, and would
 129     probably involve a function pointer [perhaps in conjunction with a data
 130     object], or other signaling facility.  Such a parameter could be useful for
 131     coordinating writes and reads to and from a shared memory object.)
 132 - - 2009-03-06 03:08:19.392472 Z
 133   - David Hilvert <dhilvert@auricle.dyndns.org>
 134   - commented
 135   - |-
 136     Note that, rather than taking simply a closeability parameter, set_file_static could
 137     take a callback and associated data parameter, to allow for more generic operation,
 138     likely with such callback and data type arranged to allow for fclose and the passed
 139     file argument to be used as callback arguments.
 140 - - 2009-03-06 03:23:19.348964 Z
 141   - David Hilvert <dhilvert@auricle.dyndns.org>
 142   - commented
 143   - |-
 144     Note that any set_host_static callback parameters should probably allow for
 145     specifying free() and an argument for this.
 146 - - 2009-03-06 13:25:26.379160 Z
 147   - David Hilvert <dhilvert@auricle.dyndns.org>
 148   - commented
 149   - |-
 150     _static and _dynamic variants of set_file and set_host have been established
 151     within the API, the static variant having associated callbacks for releasing
 152     data.
 153 - - 2009-03-06 13:50:28.419930 Z
 154   - David Hilvert <dhilvert@auricle.dyndns.org>
 155   - closed with disposition fixed
 156   - ""
 157 git_branch: