On Jul 30, 2011, at 4:40 AM, Jose wrote:
On Sat, Jul 30, 2011 at 5:08 AM, Daniel Larimer <dlarimer@gmail.com> 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