Project

General

Profile

Bug #503

Replace use of obsolete memalign function with posix_memalign

Added by Lukasz Wesolowski about 5 years ago. Updated over 2 years ago.

Status:
Rejected
Priority:
Normal
Category:
-
Target version:
-
Start date:
05/30/2014
Due date:
% Done:

10%

Estimated time:
5.00 h
Spent time:

Description

The following description in the memalign man page provides some very good reasons to justify replacing all the use of memalign with posix_memalign:

On many systems there are alignment restrictions, for example, on buffers used for direct block device I/O. POSIX specifies the pathconf(path,_PC_REC_XFER_ALIGN) call that tells what alignment is needed. Now one can use posix_memalign() to satisfy this requirement.

posix_memalign() verifies that alignment matches the requirements detailed above. memalign() may not check that the boundary argument is correct.

POSIX requires that memory obtained from posix_memalign() can be freed using free(3). Some systems provide no way to reclaim memory allocated with memalign() or valloc() (because one can only pass to free(3) a pointer gotten from malloc(3), while, for example, memalign() would call malloc(3) and then align the obtained value). The glibc implementation allows memory obtained from any of these three routines to be reclaimed with free(3).

The glibc malloc(3) always returns 8-byte aligned memory addresses, so these routines are only needed if you require larger alignment values.

History

#1 Updated by Eric Bohm over 4 years ago

  • Assignee set to Michael Robson

#2 Updated by Michael Robson over 4 years ago

  • % Done changed from 0 to 10
  • Status changed from New to In Progress

I generated a list of locations to fix with the following command in charm/src: grep -nr memalign * | grep -v posix

I was going to post the results here but it's a fairly long list. Let me know if any of these are incorrect.

Also, posix_memalign returns an error code instead of the pointer (that's now an argument). I'm unsure on the general Charm++ philosophy on error codes for system functions. Should I wrap error checking in CMK_DEBUG flags (or something similar, I'm not sure what the default is and this is just a guess)?

#3 Updated by Jim Phillips over 4 years ago

Please only use CMK_DEBUG to conditionally compile tests for conditions that are actual bugs, not tests for error conditions that are merely rare, such as running out of memory.

#4 Updated by Phil Miller about 3 years ago

  • Status changed from In Progress to New
  • Priority changed from High to Normal

This is clearly not 'High' priority, since it hasn't been worked on in over a year and no one has cared.

Also, no indication that it's actually 'In Progress'.

#5 Updated by Dong Hun Lee over 2 years ago

  • Status changed from New to Rejected
  • translation missing: en.field_closed_date set to 2017-02-06 17:11:43.012578

There is a primary concern of whether posix_memalign would be portable, and the usage of memalign for the linux builds are considered to be obscure and very narrow case to see the benefit of replacing.
After consulting with Michael and Phil, it was suggested to be rejected.

Also available in: Atom PDF