Ticket #167 (new todo)
custom class allocator delegating to mpool
| Reported by: | ichthyo | Owned by: | |
|---|---|---|---|
| Priority: | lesser | Milestone: | 1alpha |
| Component: | lumiera | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | #126, #168 |
Description
build a simple per-class custom allocator, which in turn delegates to the mpool service in the backend. This is nothing fancy, just a correct implementation of operator new and operator delete, together with a unit test to prove its effectiveness.
Change History
comment:2 in reply to: ↑ description ; follow-up: ↓ 3 Changed 3 years ago by ct
Replying to ichthyo:
build a simple per-class custom allocator, which in turn delegates to the mpool service in the backend. This is nothing fancy, just a correct implementation of operator new and operator delete, together with a unit test to prove its effectiveness.
mpool is in lib, as it is stateless, you create your own mpools for some purpose. These may (should) hook into the resourcecollector. The resourcecollector is currently in lib too, despite it has some global state, maybe we shall move it to common or backend.
comment:3 in reply to: ↑ 2 Changed 2 years ago by ct
Replying to ct:
Replying to ichthyo:
build a simple per-class custom allocator, which in turn delegates to the mpool service in the backend. This is nothing fancy, just a correct implementation of operator new and operator delete, together with a unit test to prove its effectiveness.
mpool is in lib, as it is stateless, you create your own mpools for some purpose. These may (should) hook into the resourcecollector. The resourcecollector is currently in lib too, despite it has some global state, maybe we shall move it to common or backend.
the resource collector will move to the backend and augment the mpool proactively, nothing to care about for mpool users see ticket #521
