-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org]On Behalf Of Matthew Vogt
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.
Yes. This was also in the ActiveObject pattern. It was on the "client- side", i.e. available to the thread that submits Method Requests as a means to acquire the results.
While I understand its place in the ActiveObject pattern I would hope that if a boost::active_object came into existence, there would be a single (i.e. not _simple_) mechanism by which data passed from one thread to the other, with an associated notification. In a behavioural sense, the future mechanism wouldnt be appropriate for this.
To my way of thinking, the advantage of the active object is that all its methods are processed in a single thread, preventing concurrent access to any of its resources. Unless there is only a single resource, then the active object denies opportunities for overlapping concurrency that would be inherent through the use of other designs. The upside I can see is the simplicity for the client, in that they needn't be aware of any issues relating to concurrency.
yeah baby. with some talk of the overheads its nice to touch on some benefits. simplicity of client and simplicity of servant (or active object). i have accidentally implemented something very similar to the ActiveObject pattern. recently i have had to apply that implementation within a codebase involving millions of lines of code - and it worked! there were expected benefits along the lines of what you mention but there were some pretty wild ones as well. cant really give a full explanation without consideration of my employer but heres a summary. without an active object approach, development has to deal with the "normal" issues anyhow, e.g. encapsulation/OO and concurrency. code actually "grows" according to certain rules that cant be ignored by anyone (or it dont work :-) imposing the active object model "over the top" of this type of code went well because the model is a model of what we do! thats sounds too cute but there it is. a class had been written that needed to be a thread - so it was. it had its own message queue and mechansims for submitting work. there was a second class that was a proper encapsulation of significant function - it deserved to be a separate class. it was only ever accessed by the first class. after "activating" this code, the previous interfaces (pre-existing message queue and sync methods) were left entirely alone. but with the new (completely distinct) message queue, we could exchange messages with the first class (instance, of course) _and_ with the second (cos it was a uniquely identified servant owned by the first class). this was a pleasant surprise. dont know that this case study reads very well so i'll go out on a limb - first class was a DNS server and the second was a DNS cache.
Of course, an active object could internally contain any number of threads, provided that correct internal synchronisation was maintained.
Allowing the use of asynchronous I/O seems to break the abstraction, which leaves me wondering why the object should be active? (This is in the context of *local* objects, BTW - if the object is remote there is very little difference between a client/server solution and one using active objects, is there?)
Apologies in advance if I'm not getting something obvious...
all bang on, as far as i can tell anyhow :-) we're all swimming up the same creek i think. cheers, scott