Matthew Vogt <mvogt <at> juptech.com> writes:
Really? I think it corresponds fairly closely to the pattern described in the paper by Lavender and Schmidt; it's a limited form of the *potential* pattern, in that it enforces a single execution thread for the active object. More complicated schemes could certainly be created, but not without creating constraints on the type to be wrapped. The reference paper describes the use of a single thread...
and replies to self: Actually, the paper does note that for performance reasons, the thread could be replaced with a thread pool. This requires support, however, in that the Method Request needs to be able to lock the resources needed to perform the task prior to doing so. In terms of my wrapper, the object wrapped needs to have 'hooks' for locking its resources, and the active<> wrapper class would need to have a policy class to perform the 'Scheduler' role, which knew enough to use the resource locking hooks. I considered adding a policy for this, then I would have to change the subject line to read 'Complex active object wrapper' :)