Re: [boost] asio review extended till Dec 30th

From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2005-12-29 09:54:36

On Fri, 30 Dec 2005 00:03:31 +1100 (EST)
Christopher Kohlhoff <chris_at_[hidden]> 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).