Re: [boost] Thread_Development

From: William E. Kempf (wekempf_at_[hidden])
Date: 2002-11-06 09:43:30

Matt Hurd said:
> Hi,
>
> Thanks for all the work you guys do.  Gives life a little boost...
>
> I'm getting a some untidy memory faults on a simple thread program using
> the elegant boost thread library from the thread_development tag with
> VC7 on process exit.

Well, what do you expect on a development branch ;).  Don't expect
anything there to be stable.  But thanks for the report any way.

> Might be related to this link warning...
>
> Creating library Release/boost_thread_play.lib and object
> Release/boost_thread_play.exp
> tss.obj : warning LNK4217: locally defined symbol _on_thread_exit
> imported in function "class std::vector<struct std::pair<int,void
> *>,class
> std::allocator<struct std::pair<int,void *> > > * __cdecl `anonymous
> namespace'::get_slots(bool)"
> (?get_slots@?A0x898b778b@@YAPAV?$vector_at_U?$pair_at_HPAX@std@@V?$allocator_at_U?$pa
> ir_at_HPAX@std@@@2@@std@@_N_at_Z)

boost_thread_play.lib isn't part of the development branch, so I'm not
sure that the error isn't in something you've configured locally.

> This is from a rw_mutex.html example.  The html is unfinished.  I took
> the example code at the bottom and cleaned up a few typos.  You might
> like to use it to replace the example in the code, see below.

All of the examples in the new documents are likely completely wrong ;).

> The existing win32 mutexes use critical sections.  I see there is some
> support for shared memory in thread development.  Would love to see some
> policy perhaps for win32 mutexes so it would be possible to use a cross
> process mutex, such as the win32 mutex object.  This would be especially
> useful for win32.  Could see a whole bunch on interesting policy
> possibilites for this library but I'm just a simple fellow...

Planned, but not as a policy.  We'll be using attribute objects, similar
to POSIX, instead.  In fact, there's progress being made on this very
specific attribute that's not been checked into the development branch
yet.

Thanks,

-- 
William E. Kempf