On 4/7/06, Roland Schwarz <roland.schwarz@chello.at> wrote:
Felipe Magno de Almeida wrote:
I'm using an AMD64 X2 and sometimes the program fails with the debugger showing me this call stack: [ snip ]
Unfortunately at the moment none of the developers seems to have access to a 64 bit machine. I will try to improve on this situation, but have to ask for patience until we have access.
I forgot to mention! I'm compiling to x86. It seems the problem is due to boost::thread_specific_ptr<ptr_t> being a local static variable in get_definition on grammar.ipp in spirit code. line: 224 in grammar.ipp # ifdef BOOST_SPIRIT_THREADSAFE static boost::thread_specific_ptr<ptr_t> tld_helper; if (!tld_helper.get()) tld_helper.reset(new ptr_t); ptr_t &helper = *tld_helper; # else The .get member function is called before the tld_helper is fully constructed (and, as a consequence, the tss_data in tss.cpp isnt initialized too. So in line 114 - tss.cpp - ::get_slots slots = static_cast<tss_slots*>( TlsGetValue(tss_data->native_key)); tss_data isnt initialized yet. I think the only relevance is that it is a dual core. Which makes two parse's functions being called concurrently on a local static. The pretty bad workaround I made was adding boost::call_once(&init_tss_data, tss_data_once); as the first line to get_slots. But the real problem is that local statics arent thread safe, and a member-function is being called before the object being fully constructed. Unfortunately I dont have more time to invest coding any better solution right now. Nor understanding boost.thread/boost.spirit internals. It seems to me that thread_specific_ptr has a broken interface and documentation, since it doesnt address the local static thread-safety issue. Which leads users to use it erroneously. I dont know now if I should move the thread to spirit, as a spirit thread-safety bug. What do you think?
Regards Roland
Thanks, -- Felipe Magno de Almeida