Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-09-07 08:03:41

--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: "William Kempf" <williamkempf_at_h...>
> > From: "Peter Dimov" <pdimov_at_m...>
> >
> > >condition.cpp does not compile when the macro NOMINMAX is not
> >
> > 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.

OK, hopefully I have enough info to try and diagnose this. Didn't
find the time last night and won't until tonight, but I'll get to it

> > I also don't see any use of call_once in the above?
> thread_specific_ptr<> uses call_once internally to initialize its
> handler std::set. (Why isn't it a std::map, BTW? Looks like you
are 'faking'
> a map with a set?)

Ahh. That helps to.

As for why I didn't use a map... chalk it up to a very long day of
trying to get this concept to work at all ;). I'll fix that while
I'm at it.
> > 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.

May take a while, but if there's a bug I'll fix it :).

Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at