5 ms·
Very interesting article, especially the t_scope allocator - I never knew you could get GCC to perform that cleanup automagically. One minor grammar point: isn'
by cs648 13y ago
Very interesting article, especially the t_scope allocator - I never knew you could get GCC to perform that cleanup automagically. One minor grammar point: isn't a lock under contention a contended lock, not a contented lock?
- fruneau 13y agoWording issue fixed.
- dman 13y agoIs the source for the allocators freely available? Would love to study those.
- fruneau 13y agoUnfortunately, not for the moment.
- aktau 13y agoI'd also like to put in a request for either open-sourcing or a more detailed overview of the implementations, they sound really interesting.
- fruneau 13y agoI'll consider writing a more detailed article on the subject. Open-sourcing the code will not be possible in the short-term.
- deletes 13y ago+1, for request of implementation details. I'm really curious about this.
- robjh 13y agoIn lieu of the implementation, I'd like to know if these allocators are themselves based on malloc or if you have some tricky assembly/kernel code going on somewhere.
- fruneau 13y agoThese allocators are based on mmap to build the arenas.
- epistasis 13y agoYes, I wish that cleanup was a portable C feature! Glad to see that GNU is trying something here, as it would serve as a prototype for standardization. Perhaps in a future version of C...
- qznc 13y agoThere is an extended version of C, which is has this feature and is nearly as widely ported as C. They aptly named it C++.
- epistasis 13y agoC++ has an IMHO worse version of this feature, that requires a custom type, and that only allows a single function to be called for that type. This is more like Go's defer, and is far more appropriate for my use cases.
- vidarh 13y agoI haven't written much C++ in quite a few years - mostly do Ruby these days, so I'm sure I'm making some terribly embarrassing faux pas or other with the example below. But you don't need more than the C++ functionality to compose your own variations if you want more flexibility. For example: #include <vector> #include <iostream> class Scope { private: typedef std::vector<void (*)()> FV; FV fv; public: void on_return(void (* f)()) { fv.push_back(f); } ~Scope() { for (FV::iterator it = fv.begin(); it != fv.end(); ++it) { (*it)(); } } }; void foo() { std::cout << "Hello "; } void bar() { std::cout << "World" << std::endl; } int main() { Scope scope; scope.on_return(foo); scope.on_return(bar); std::cout << "Hi" << std::endl; } With C++11 lambda syntax you can do quite a bit better. Expanding that into something providing at least most of what Go's "defer" does shouldn't be too hard.
- epistasis 13y agoGood idea, this definitely accomplishes the same functionality, but it's done at runtime, rather than the compiler knowing all the functions at compile time. Perhaps a minor difference for most cases, though... I would still prefer a C extension... Perhaps I should just use Go these days, though ironically all these memory allocation policies are useless in a GC language.