Thread-safe subscriber count

[oscarthorn]

Hej!

This is a really nice project, really happy to have found it!

I'm trying to figure out a decent way to get the number of subscribers to a topic in a thread-safe way. I have a program that basically runs in a loop and on every iteration it sends out some data to clients. It has fairly hard realtime requirements on limited embedded hardware. Calculating what to send is non-trivial and if we the client (usually only 1 or 2 clients per device) is not requesting that data we don't want to send it.

Getting the number of subscribers is easy with:
_app->topicTree->lookupTopic("topic")->size();

But that's not safe is it? The topic might be de-allocated at any time, due to unsubscribe.

I might use defer to execute this but then there is no great way to get the answer. Just setting some atomic variable might be fine but then I also have to deal with the fact that defer might not immediately execute the lambda.

I could also keep track of subscribe, unsubscribe and close calls and count the number of subscribers but that seems a bit convoluted for information that is already sort of known.

Any suggestions? Have I missed some simple solution?

[oscarthorn]

Of course right after typing this up I figured out there is a subscription callback, which makes keeping track externally quiet convenient. Really thought I looked everywhere. Sorry! But hopefully this can be a pointer in the right direction for others.

[uNetworkingAB]

Nothing in the library is thread safe, except for Loop::defer but it will never run immediately and it is costly. So you really want to segment/isolate connections to one single thread and keep them there.

[oscarthorn]

Thanks for the answer!

Sort of unrelated. How long is the wait usually for defer? Like in what order of magnitude? Is it milliseconds? It seems like using defer is the only option, or am I missing something? Seems like my situation would be common, that I need to send data initiated by the server from another thread (since the uWS thread is occupied by uWS).

[uNetworkingAB]

You aren't supposed to cross threads. The idea is to share the same event-loop for all your IO. That's why we support ASIO, libuv and others to have a seamless integration. It's a common hack for C++ devs to just "fix it with more threads" but it makes things half assed compared to a proper integration on the same event-loop. Mixing threads is a poor solution regardless.

[oscarthorn]

Okey, thanks! This is part of an application that uses ROS, which has its own eventloop so integration is not straightforward. But thanks for the suggestion.