Subject: Re: [boost] [rpc] Introducing Boost.Reflect, Boost.CMT, and Boost.RPC
From: Daniel Larimer (dlarimer_at_[hidden])
Date: 2011-07-30 16:36:12
On Jul 30, 2011, at 4:40 AM, Jose wrote:
> On Sat, Jul 30, 2011 at 5:08 AM, Daniel Larimer <dlarimer_at_[hidden]> wrote:
>> I am torn about making boost::cmt depend upon boost::reflect vs introducing yet another library called boost::actor and then having
>> boost::rpc depend upon boost::actor.
> Maybe you could have actor, rpc, cmt be part of concurrency toolkit ,
> much like asio does for async networking (reactor, proactor and async
> with threads).
> e.g. mpt for message passing toolkit
Not a bad idea, but I like small, well-defined libraries as they are easier to review and
contain dependencies. Perhaps the unified concept of 'message passing' where inter-thread, inter-process,
and inter-machine are all handled 'in the same way' could work.
> I would assume with this library you could have the message passing
> programming benefits you get with Erlang.
Yes. I have been using tools similar to these libraries (but not as clean or generic) and I can testify that
attempting to develop any application that deals with asynchronous events or multiple threads is greatly
enhanced and simplified by using CMT.
>> Awesome appears to provide stackless coroutines whereas CMT uses Boost.Context to provide a real stack per fiber.
> Maybe your library should also provide both approaches. There are some
> important shortcomings for stackful coroutines. Can you comment on
> those ?
The main shortcoming is allocating stacks and actual context switching. Using stackless solutions
requieres the user to manage their yield points. I have developed code using stackless approach and
it helps, but does not solve the problem of ASIO callbacks happening in a separate thread and thus
accessing shared state from an asio handler becomes problematic.
> Many thanks for sharing your work
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk