Exiting from EzRpcServer

[Richard Hacker]

Hello

while EzRpcServer is a very easy two liner to use on its own (see
ez-rpc.h), it is daunting to use RPC outside this context.

My application is a data collection agent. While it is gathering data
from its sources as a TCP client, at the same time it also serves this
data to other clients connecting to it using capnp RPC. It uses ASIO as
an event loop, but the problem would not change when using kj's event
loop. To detach the data collector from the RPC server, I want to launch
the RPC server in a thread of its own.

The problem I am facing is how to shut down the RPC server thread from
listening and its (long running) clients explicitly so that the main
thread can join() the RPC thread. While EzRpcServer implementation is
very short, I have no clue as to where I should start.

Since the RPC server is running in a thread of its own, it can run its
own EventPort, although merging it into ASIO's event loop would be the
silver bullet, but I guess quite an integrate task.

In the long run, I would also like to use RPC Client from a Qt
application, this time it should be running instde Qt's event loop, but
that is another story.

Any hints would be very welcome

Mit freundlichem Gruß

Richard Hacker

--
------------------------------------------------------------------------

Richard Hacker M.Sc.
richard...@igh.de
Tel.: +49 201 / 36014-16

Ingenieurgemeinschaft IgH
Gesellschaft für Ingenieurleistungen mbH
Nordsternstraße 66
D-45329 Essen

Amtsgericht Essen HRB 11500
USt-Id.-Nr.: DE 174 626 722
Geschäftsführung:
- Dr.-Ing. Siegfried Rotthäuser
- Dr. Sven Beermann, Prokurist
Tel.: +49 201 / 360-14-0
http://www.igh.de

------------------------------------------------------------------------

[Kenton Varda]

Hi Richard,

In the RPC server sample code, there is a line like this:

    kj::NEVER_DONE.wait(waitScope);

This waits forever, running the event loop.

If you don't want the loop to run forever, the trick is to wait on a promise that resolves at some point. For instance, you could create one:

    auto [promise, fulfiller] = kj::newPromiseAndCrossThreadFulfiller();

    promise.wait(waitScope);

Now, some other thread can call `fulfiller->fulfill()` to cause the `promise.wait()` to return.

It would also be possible to make the KJ event loop run in the same thread as ASIO, but this would indeed be a lot of work -- you would essentially have to implement the KJ I/O interfaces in terms of ASIO, instead of using UnixEventPort.

-Kenton

--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/c67b1261-d39c-4138-8feb-55f045236986%40igh.de.