Re: Yet more on boost.threads

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 
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.

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 
ASAP.

> > 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?)

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