I've posted a link to an older version in another thread : http://www.qtcentre.org/forum/f-qt-p...tion-6838.htmlAbout the allocator/deallocator: if you don't manage to solve it, you may as well post it, maybe we can find some solution.
Sure!, It's packed with the allocator code
I don't use QReadWriteLock, Qt does...Why don't you use a QMutex instead of a QReadWriteLock?
One appears to be enough and is safer because otherwise parallel alloc/dealloc would be allowed which would be quite bad...I believe a QMutex( actually you need two ) is more trustworthy. You could trace the errors easier than with a rw lock.
That's what I was thinking about but there does not seem to be a standard and portable way to achieve that...Obviously the trick from the beginning of the thread is neither working or portable (the compiler may change the order of calls if it finds it useful).
A general answer is that you need your own startup code for that. One that doesn't call main() but first executes your code and only then jumps to the starting address of the application (not "main"!). On Linux you could probably use a preload object with a small assembly code that does what I explained, but this certainly won't be portable. A portable solution is hardly doable for an already built application (when you can't substitute the startup code directly yourself).
OK, that was for the answers! The nice thing is that, after some hard work I've been able to fix it all :
Only one problem left : QLibrary now refuses to load my plugin... I'll see if it comes from an error of mine or a broken internal...
- There must have been a problem in the allocator but rewriting its internal functions seems to have fully fixed it
- A tricky singleton alternative pattern fixes the problem of prior initialization of the pool before any new call. The only downside is that the size of the pool becomes fixed on compile time... Will do for my purpose so it's not so embarassing after all...
Thank you all for your advices.![]()
Bookmarks