3 ms·
> This sucks, but if we make the assumption that no destruction shall happen during an async context, it’s kind of fine (Oh boy, this will definitely make peopl
by naasking 2y ago
> This sucks, but if we make the assumption that no destruction shall happen during an async context, it’s kind of fine (Oh boy, this will definitely make people jump out of their seat). On a side note, I have yet to see a proper solution to that, and I would like to avoid having double pointed types to solve the issue – if anyone has an idea, feel free to send me a message or send a pull request on the github repository.
An async context marks pointers to destroy rather than destroy them immediately (defer destruction by unqueueing them), and a dedicated thread periodically wakes and processes the queue of marked objects. It must should be processed on another thread because the object is by definition no longer reachable from the original thread since it's marked for destruction.
- Spivak 2y agoI'm assuming the OP is doing this specifically to avoid implementing a GC so I'm not sure this approach would be satisfactory, but it would work.
- naasking 2y agoYou wouldn't need to spin it up it if you don't use "async contexts", and the GC only collects objects freed during those contexts so it can be very limited. You could eliminate it entirely if your program threads periodically call into a cleanup function manually to process this queue. The point of the thread is to make this automatic since that's ostensibliy the whole point of smart pointers.