On Fri, 30 Dec 2005 00:03:31 +1100 (EST) Christopher Kohlhoff <chris@kohlhoff.com> wrote:
As you mentioned, threads are required for the async DNS lookup.
This has never really come up, and to my knowledge you are the first to ask for the ability to build without using thread support.
I can check for BOOST_DISABLE_THREADS (in fact I've already made some changes along this line), but when threads are disabled functionality like asynchronous host resolution will have to be made unavailable.
That's a start, I guess (though I'm not sure what macros to check). However, this still propogates the current misuse, IMO, of how threads are to be specified. I'm sure there are many alternatives, but the first to mind (yet probably undesirable), is to fork a process and use IPC mechanisms and a very simple protocol in the absence of threading. Maybe you could make it policy based instead of ifdef'd. Of course, if the multithreading plicy is chosen, then the code should throw the #error if multithreading is not defined. I certainly do not think #threading should be mandatory for this library. In fact, you do not #want it to be multithreaded. You are going to be running the demuxer #from a single thread. You may do other things (like toss work on a #message queue for another thread to process -- especially long term #operations that can not be multiplexed into the asio framework). #However, the control flow for the demuxer will be executed in a single #thread, and should not be doing anything with synchronization #primitives. First, I should apologize for my tone in the last email. I just read it, and it did not come across very friendly, to say the least. I can try to blame it on being frustrated with something else, but it's most likely due to me just being a grumpy old man. Anyway, I think the current threading practice we use in boost is just plain wrong. It's no fault of yours that you are simply following that practice. I should be able to specify pieces of code that do not touch multithreading issues. Unfortunately, too much code simply adds multithreading into everything. Part of what bothers me is that boost is a modern C++ library, and as such has many tools to allow different practices, yet we still use IFDEFs and blindly insert synchronization primitives in places where they are not needed. If certain pieces of my application are known to be single threaded, then I want to compile it that way. However, I also may have other pieces of my application that are multithreaded, and I want to compile them that way as well. With boost, this is virtually impossible. You have to declare one or the other. I'm not sure of all the places this actually happens, but some of the core libraries do it, so it permeates. Further, other libraries seem to take the same stance. I find this very disturbing. I'm actually home sick, so I don't know how much I'll get done (it also may have something to do with my sour disposition, though I REALLY wish we would address this issue boost-wide).