multithreading and execution context

[dvhwgumby]

My app is multithreaded and any thread can arbitrarily make an RPC or publish info.

Are transmissions automatically serialized on a common asio strand? At the moment I require that all transmissions be queued and have a thread that does nothing but pop requests from the queue and send them to websocket-cpp. I would love to simplify this code if this queueing process is redundant.

On the callee side: I assume the RPC execution context is one of the io_context's threads, so all of my RPC handlers simply pass the requests onto a work queue. Again, this is clumsy if unneeded, though of course a more general mechanism is harder to design.

In either case: could you clarify what's going on so I can write the right thing? The examples are simple for important pedagogical reasons but don't illuminate these issues.

Thanks,
d

[ecorm]

See #43, #146, and #156.

Asio was updated in Boost 1.66 release. There's mention of executors in this new documentation page: http://www.boost.org/doc/libs/1_66_0/doc/html/boost_asio/net_ts.html . I'm too busy with work/life right now to investigate any deeper.

[oberstet]

@dvhwgumby "executors" define the context in which a future is resolved, and the executor can be specified in a parameter to .then(etc), eg:

session->join("realm1").then(boost::launch::deferred, [&](boost::future<uint64_t> joined) { ... }

https://github.com/crossbario/autobahn-cpp/blob/master/examples/callee_new.cpp#L92

boost::launch::deferred will resolve the future on the same thread that created the future, in this example, the main thread (and in this example, the whole program is single-threaded, and fully relying on async to make concurrent stuff possible).

there should be a way to create a new executor on top of a thread pool (with only 1 thread), and then provide that executor to .then in the calling threads.

I agree: we should have examples/docs for non-basic use cases as well.

[oberstet]

the sad truth so still seems to be, that executors are still in incubation (boost), not standardized yet:

• https://stackoverflow.com/questions/44189180/why-are-executors-not-in-concurrency-ts-and-in-the-stdfuture-interface-anymore
• http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0443r1.html

as all the main languages are adding the full machinery for async, C++ is kinda late to the party, and due to the complexity of the language, probably only C++ 20 will have all the bells and whistles standardized. eg co-routines also

that being said, compilers nowerdays often already have such pre-standard stuff already built in - or boost.

[oberstet]

@dvhwgumby OT: PDP11? 👍 :) I was exposed a little to VAX stuff via my father as I was a teenager in the late 80s, when I was into Amiga etc. - and that different world always fascinated me (meters of weirdo manuals). so sad that DEC (and SUN) passed away .. so many breakthrough/first technologies .. VAXCluster ..

[dvhwgumby]

So sounds like I need the two-thread+private-queues serialization for now.

semi-OT @oberstet I think the async structure of ASIO and the networking elements of ASIO need to be teased apart before standardization. The proactor framework etc should really be part of the concurrency section of the standard and network abstraction in the networking TS. I don't see how that could happen, be implemented, and have people have enough experience with it before 2020.

OT: @oberstet I was mainly a PDP-10 programmer -- the PDP-10 was a different architecture completely: 36-bit word with 18-bit addressng and a RISC architecture all designed in the early 1960s with the objective of building a high-performance Lisp machine. All the Internet development up through TCP and IP was designed with these machines in mind and you can still see things in the packet layout etc that were a result of this, and could look odd on today's machines where, for instance, bytes are always 8 bits wide (on a PDP-10 they could range from 1-36 bits). The same phenomenon is why programming in C always makes me think I'm programming a PDP-7 or PDP-11.

The Vax was an overgrown PDP-11, but still had a short 32-bit word. All its bytes were 8 bits wide though. I never really used one as I didn't like the smaller word size or CISC instruction set :-)