Boost logo

Boost :

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2005-09-05 01:41:01

Christopher Kohlhoff wrote:

>--- Roland Schwarz <roland.schwarz_at_[hidden]> wrote:
>>Why not simply use boost threads once function instead?
>Does it address the issue of order of cleanup with respect to globals?
This is indeed one of the hardest problems, specially when dealing with
global objects.
E.g. there is a problem when the main thread is ending, but some other
thread are
living even longer. I vaguely remeber some recommendation not using
these globals
in MT at all. But I am not too sure. Also this sounds much to prohibitive.
Me for my part always ended with some kind of reference counting. This
btw. is
what WSAStartup/Cleanup seemingly is doing inside. But I think you could
move the ref-counting into your code to be independant of WSAStartups
E.g. you could simply wrap up things into a shared_ptr.

>>I also discovered another issue:
>>The number of demuxers is implicitely limited by available TSS slots.
>>This also is an issue that long ago has been succesfully solved in
>>the threading library.
>Yes, although the demuxer's use of tss is to keep track of whether the
>current thread is "in" the demuxer. The problem I had with the boost
>tss when I first investigated it a couple of years ago was that it
>seemed to involve storing an object in tss, when all I really wanted
>was a thread-specific boolean flag (and I had no need for cleanup).
Not sure if I understand this correctly. You are using ::TLSFree don't you?
Besides how about
boost::thread_specific_ptr<bool> pbool;
pbool.reset(new bool); ?
The thread_specific_ptr is doing almost what your class win_tss_bool is
to do anyways.

>>A final question is poping up:
>>Why not using the boost threading? Or is this planned for future?
>It doesn't use boost threads internally so that it can keep the library
>header-file only, i.e. to avoid adding a dependency on any non-system
>DLLs or libraries.
I know this might seem a little ignorant, but could you please give me
your rationale for
"header only" ?

> But if a future boost threads release was
>header-file-only for the most commonly used bits (threads, mutex,
>condition)... ;)
There is currently a rewrite going on. I will try to drop this into our
bag, but I am not
currently convinced that header only really is a win, but I would like
you proving
me wrong. Good arguments could give raise to a header only
implementation of basic
locking primitives too.


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