This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients benjamin.peterson, neologix, njs, pitrou, rhettinger, skrah, tim.peters, trent, vstinner, wscullin
Date 2017-10-25.14:33:21
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1508942001.5.0.213398074469.issue18835@psf.upfronthosting.co.za>
In-reply-to
Content
Currently, the main question on my PR 4089 was raised by Antoine Pitrou:
"Do people have to provide aligned_alloc and aligned_free? Or can they leave those pointers NULL and get a default implementation?"

My reply: "Currently, you must provide all allocator functions, included aligned_alloc and aligned_free. Technically, we can implement a fallback, but I'm not sure that I want to do that :-)"

I'm not sure about that. I can imagine platforms which provide a special malloc/free and that's all: no calloc, posix_memalign or _aligned_malloc(). But is Python suppose to fills the holes? For example, implement calloc() as malloc()+memset()? Or is the user of the PyMem_SetAllocator() API responsible to reimplement them?

In Python 3.5, we added the requirement of a working calloc().

In Python 3.7, should we also add the "aligned alloc" requirement?

In case of doubt, I prefer not to guess, and leave the decision to the caller of the API: require all functions to be implemented.

I'm not sure that it's a good idea to provide a "aligned malloc" fallback if such fallback would be inefficient. For example, we would have to overallocate the memory block not only for the requested alignement, but also allocates extra sizeof(size_t) bytes, *in each* aligned memmory block, to store the size of the alignment itself, to recover the original pointer... to finally be able to call free().

An aligned memory block would look like: [AAAAA SSS DDD...DDDDDDD] where AAAAA are bytes lost for alignment, SSS bytes storing the alignment size (size of "AAAAA" in this example), and "DDD...DDDDDDD" would be the actual data.
History
Date User Action Args
2017-10-25 14:33:21vstinnersetrecipients: + vstinner, tim.peters, rhettinger, pitrou, benjamin.peterson, trent, njs, skrah, neologix, wscullin
2017-10-25 14:33:21vstinnersetmessageid: <1508942001.5.0.213398074469.issue18835@psf.upfronthosting.co.za>
2017-10-25 14:33:21vstinnerlinkissue18835 messages
2017-10-25 14:33:21vstinnercreate