Changed buffer API to receive policy instance. It may be necessary for the other back-ends, where dynamic memory is not available and custom memory allocator may be provided by a custom policy.
Diff Detail
- Repository
- rPSTL pstl
Event Timeline
I don't see a big problem with this change per-se, but can you please expand on the bit where you say:
It may be necessary for the other back-ends, where dynamic memory is not available and custom memory allocator may be provided by a custom policy.
How would you somehow handle allocation through a custom policy?
Assuming, at some point we figure out how to get p0443 executors and p1019 style execution policy types, which communicate executors to the algorithm, which allocator to use becomes a property query against the executor. The default executor and it's associated properties are a library implementation detail, but the way that the algorithms respond to the presence of those properties should be the same.
Similarly, the execution policy will ultimately need to be communicated to the basis functions of the backend as well, and I am planning on resurrecting my prototype of that change in the next week.
I'd like to be careful about making these sorts of changes until we have had a chance to have the next follow up coordination meeting that Alexey has proposed.
For example a custom policy has get_memory_pool method which provide an interface for memory allocation/access.
Of course, this "contract"(provided by a custom policy) must be known a custom corresponding parallel back-end as well. But Parallel STL core implementation have not to know about this "contract".
I agree with Thomas, in that case it is connected with the executors, because the custom policy specifies certain "backend"... and works like an "executor". And in the future, just an executor should specify back-end.
On the the other hand, "the executors" are not finalized yet.. and it may take many time (months mb). The change so minor.. and the change helps us to sync-up, and when an "executors solution" comes, we will change the code places quickly. That change may not be taken for libcstd integration.
My main problem with this change is that we don't seem to have a backend right now that requires this change. I'd defer doing this until we have a real reason to do so.
At least, it "extends" signature of functions of a back-end that helps (now) to support several back-ends in the same time (by overloading).
[Github PR transition cleanup]
Libc++ doesn't use the code under /pstl/ anymore, so I am neutral on this.