Re: [boost] RE: Yet more on boost.threads

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-09-07 04:55:14

From: "William Kempf" <williamkempf_at_[hidden]>
> From: "Peter Dimov" <pdimov_at_[hidden]>
>
> >condition.cpp does not compile when the macro NOMINMAX is not defined.
>
> I'll add the macro before the includes.
>
> >This program:
[..]
> >sometimes prints 1, 2, ..., 7 (note absence of 0) and sometimes locks up
my
> >machine. (I'm using MSVC.) This happens only in Release builds, not in
> >Debug; I suspect that 0 is not printed because the catch(...) handler in
> >thread.cpp eats the access violation. The problem is probably in
call_once.
>
> What access violation?

The access violation. Weird, I know. It happens somewhere in
boost::call_once(init_cleanup_key, once) in tss.cpp, AFAICS, but I may be
wrong. It's very difficult to debug on 9x since you never know whether it'll
be Big Red Button time.

> I also don't see any use of call_once in the above?

thread_specific_ptr<> uses call_once internally to initialize its cleanup
handler std::set. (Why isn't it a std::map, BTW? Looks like you are 'faking'
a map with a set?)

> This is very similar to code used in the test harness, which passes for me
> in both Debug and Release (the one difference being the use of
boost::bind,
> which I don't suspect as a problem).  This perplexes me.  I'll have to try
> it out myself later and see if I can diagnose any errors.

Perplexed me, too.

--
Peter Dimov
Multi Media Ltd.