Christopher Kohlhoff wrote:
--- Roland Schwarz <roland.schwarz@chello.at> 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 simply move the ref-counting into your code to be independant of WSAStartups peculiarities. 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 needing 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. Regards, Roland (Speedsnail)