BIND 10 #2088: introduce MemorySegment class

[BIND 10 Development]

#2088: introduce MemorySegment class
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  muks
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120717
  medium                             |            Resolution:
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  4
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  scalable inmemory                  |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:14 muks]:

 > When we are not able to allocate (by this, I don't mean large buffer
 requests that may fail, but smaller sizes which is unexpected), even if we
 handle this case, there's not much else to help the process then. It's an
 unreasonable condition for a typical process to continue beyond that point
 without requesting more from the data segment, even during cleanup (unless
 we just let it fail without any cleanup).

 As I admitted, I tend to agree if malloc() returns NULL for a
 reasonably small size of memory it's quite unlikely to recover from
 that situation in practice.  That's why we generally catch
 bad_alloc (as part of other std::exception) only at the top level of
 the program and only to immediately terminate.

 But,

 > It's not unreasonable to **not** handle an unexpected NULL
 > return. There are people who do it and who don't (a matter of
 > personal style from their experience).

 this is my first time to hear intentionally ignoring this case could
 be considered a style matter (at least unless it only expects
 prototype-level quality or is expected to be used in some limited
 systems where malloc() returns non NULL or makes the program
 terminate).  Any production-quality software that is expected to be
 portable I've seen catches this error mode and somehow tries to handle
 it explicitly, if only to terminate the program.  Our of curiosity,
 exactly who are the people ignoring an unexpected NULL from malloc()
 (other than you:-)?  Is there any well known project that adopts that
 style?

 > The effect being far away
 > from cause is going to happen even if we test for NULL (over
 > commiting policy).

 I don't think that's true at least if we throw an exception.  If
 allocate() is implemented this way:

 {{{#!cpp
     void* ptr = malloc(requested_size);
     if (ptr == NULL) {
         throw bad_alloc();
     }
     return (ptr);
 }}}

 unless the caller explicitly catches this exception and intentionally
 handles it in an inappropriate way (like just ignoring it and using a
 NULL pointer instead).

 > > So, to me, the only possible options were
 [...]
 > We are trying to find the best way for this. If you feel `allocate()`
 should throw, we'll add it. I don't mind both ways as I don't think either
 is less correct or makes a practical difference.

 I prefer throwing an exception mainly for the reason described in the
 previous paragraph.  If there's a reason I'm okay with pass NULL
 through to the caller, requesting the caller to handle that case
 properly.  I don't really like to just ignore this case both within
 allocate() and in the caller (and let the program die in some random
 way or go crazy).

 > This becomes an issue because code that NULL tests libc returned
 pointers will be dead code, and termination happens randomly when the
 pages are used.

 I don't understand this...sure, if a particular system ensures
 malloc() either returns non NULL or makes the program terminate, the
 if+throw in the above code snippet is effectively dead code for that
 platform.  But I don't think it will make compile error, and while the
 additional `if` is an unnecessary cost, we generally don't expect this
 code to be super efficient so the additional cost should be marginal.
 If we really care about the redundancy, we could ifdef-out that part
 for that particular system - then we can still ensure safety for
 others.  I simply don't understand the "termination happens randomly"
 part.  If malloc() could make the program terminate, termination could
 happen, but it's not because of the added if.  If this meant something
 else, I simply didn't understand it.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2088#comment:18>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development