Re: [boost] [rpc] Introducing Boost.Reflect, Boost.CMT, and Boost.RPC

Subject: Re: [boost] [rpc] Introducing Boost.Reflect, Boost.CMT, and Boost.RPC
From: Jose (jmalv04_at_[hidden])
Date: 2011-07-30 04:40:18

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

I would assume with this library you could have the message passing
programming benefits you get with Erlang.

>
> 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 ?

>> - Could you provide a more real-life example, e.g. a proxy like in the
>> above example ?

> The only thing I need to be careful about is long-running tasks that do not yield.  They can block all other tasks in a particular thread.  With boost CMT it is easy enough to spawn these tasks off into a real thread.  I try to avoid any blocking system calls as they stall not only the current fiber, but all other tasks assigned to that thread.

Having real life examples be part of the library would help users see
the benefits much quicker. I am not clear what would be the most
compelling examples
(proxy or web server are programmed best with the proactor pattern or
stackless coroutines)

- How to spawn a normal thread for blocking operations like file IO
- a Map-Reduce example on how to distribute tasks to different cores
and different machines
- a basic persistent http client example that shows how to do
pipelining (not so easy to do with proactor) and saves results to
files

I hope you propose boost::reflect for review soon and then mature all
the other bits in a library that enables other concurrency models and
is a good brother for asio.

Many thanks for sharing your work