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

From: Hurd, Matthew (hurdm_at_[hidden])
Date: 2004-02-16 18:43:32

> On Behalf Of scott
> Subject: RE: [boost] Re: Re: Future of threads (III)

> Do you guys have any thoughts on how to "get work into" the
> class (now that it is truly a running thread)? Cos this is
> the essence of what an AO is. I think :-)
> 
> Cheers,
> Scott
> 

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.

I also advocate a different architectural neutral style where you can
have things at look like function calls that can be:
    1.   a function call
    2.   a call to queue work pool or active object
    3.   an IPC mechanism for same machine transfer, e.g. shared memory
    4.   a network mechanism, TCP, UDP, TIB or something, for 

If it can be enabled by a policy driven approach then you can change the
architecture of your application by simply changing policies.

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.

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.

Regards,

Matt Hurd
_______________________

Susquehanna Pacific P/L
hurdm_at_[hidden]
+61.2.8226.5029
_______________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments.  Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited.  Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument.  Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.