Re: [boost] Re: Re: Future of threads (III)

From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2004-02-16 20:51:16

On Mon, 16 Feb 2004 18:43:32 -0500
"Hurd, Matthew" <hurdm_at_[hidden]> wrote:

> AO's should either have a queue for work or hook into a queue.  They
> are a bit like a worker pool with one worker ;-)
> 
> Another idiom is a future value, where you ask for a value and don't
> block until you "read" the value.  ACE also has an implementation of
> this.  You can think of it as a bit like overlapped I/O.

Again, as you have said previously, I think ACE has managed to handle
these ideas fairly well.  However, there still exist several ways in
which their implementation may be improved, especially if it is
decoupled from the rest of the lib.  I have used ACE+TAO for years, and
have grown accustomed to the baggage of the whole system, but I
understand the reluctance of some.  However, please note that to obtain
the level of functionality that everyone seems to desire would
necessitate a certain amount of baggage (and dependency) as well.

> I think David Abraham's named parameters could help greatly with this
> approach, along with the serialization lib for marshalling support.
> This should provide a solid basis for this.  I've also thought that
> perhaps boost::signals might be the correct approach to take for this
> but I'm unsure.

Indeed.  In fact, I have added on a piece to Boost.Signals that allows
general dispatching (still typesafe, and based on types of
signals/slots).  Boost.Signals dispatches through a specific signal
type, and my extension allows any signal type.  I have used this with
thread policies to handle interthread communication between specific ACE
threads and the main thread for wxWindows.

> To support this approach you also need mutex aspects that are also
> policy driven.  I am preparing to submit such locking that builds on
> the existing mutexes and locks.

As you can see, to push this requires almost as much underpinning as the
same mechanism in ACE.  Do not get me wrong, I am not saying that since
it is in one place, it should not be in another.  However, if
Boost.Threads goes down this path, it would be quite naive to think that
it can be done without all the drawbacks of current implementations of
the same thing.

That being said, I'd be willing to lend some time (and what some may, or
may not, call expertise) to investigate the issue from a linux point of
view (most of the discussion so far has come from the windows world, I
think).

-- 
Jody Hagins