An alternative to data processing inside callback functions?

edit

I know this is a late answer but I'm adding it after doing a review of someones code and found they had implemented it blindly because it is "recommended, of course!" by kramer.

Why do you need to move calculations outside the callback? The only case it's really valid is if you are filtering messages. Ie you expect more messages than your module can/wants to process so you need to throw away some of them, in which case the subscriber message queue will fill up so you may not be processing the latest message.

In that case either add more AsyncSpinner threads to process your callback or have a calculation thread running to process your calculations. If you use multiple AsyncSpinners then use mutexes for the data accessed across mutliple threads or make your callback stateless (only depend on the variables passed into the callback) - which is a good idea anyway.

You can also have the callback post a message into a queue (or post a semaphore) which is exactly what you did to get the message into the callback in the first place and have another thread blocking on a queue receive (or a semaphore pend) then process your data. This is the correct implementation of the producer - consumer method.

If you are running in any normal system where you aren't spamming your modules with messages and you want to process all the messages, then handle it in the callback. Handling all the processing in the callback makes the code easier to read and maintain and actually REDUCES the processing load because you are not needlessly passing data around. The data has to be processed somewhere, the more it's passed around the more overhead is added. The above answer by kramer suggests moving the processing to a Timer thread. This is the worst method of all. It means that you are now adding a polling loop into your code. It's just a pain - don't do it.

1. You have an event driven architecture given to you by ros and are using it! Don't use it to then create a polling architecture.

2. Unless you implement some checking, you won't know if you're dropping messages. Ie if 2 messages come in before the timer goes off.

3. You're adding a delay between receiving the message and processing it. If you're passing the message between many module then you might be adding a ton of latency into your system and if you aren't adding delay then you're adding a ton of processing because of the fast polling loop.

4. It's extremely difficult to profile your code and work out how much load you're inducing. If you're not sending any messages your loops are all still running checking for messages. If you're sending around lots of messages you can still only process them as fast as your polling loop so you'll likely be dropping messages and not ...