only one callback at a time?

[MichaelWallace30]

I have a call back looping to reach a new waypoint which loops until it is reached or the autonomous mode turns back on.
bool mode = false;

callbackWaypoint(mode == false)
{
while(!auto || reachedwaypoint);//calls fine
}

Then another call back command mode which turns on autonomous mode.
callBackCommand(...)
{
mode = true;//calls fine if we aren't looping in waypoint
}

What Im noticing is while the callbackWaypoint is looping I can not trigger callbackCommand. It seems the message isn't being received. This was probably not you designed intention to loop in the callback, but this means as long as a call back is being executed no messages can be received?

[MichaelWallace30]

There is a to-do with my name. Damn you Mario. I'll just put Alex's name and blame him.

[CheezBoiger]

I talked to you about this back in the summer, about thread handling. Right now, all we have is one recv thread handling callback calling, so if you have a loop in the callback, which I don't know why you would want one because the callback is suppose to ONLY store information, not perform actions for applications, then I highly advise against it. Although, since only one thread is handling this, there may be an issue with deadlock, or stalling of the commproto library, which would in turn cause horrendous issues.

I suggest we create a threadpool to deal with this issue.

class ThreadPoolExecutor {
public:

  // Have threads check for any tasks to be done in the m_tasks data structure.
  // recv thread will just store the packet and callback into a tasks struct for threads to 
  // handle themselves. This will prevent the CommProtocol library recv thread from
  // doing things that the client shouldn't be doing with, and continuously checking for
  // packets received.

private:
  struct {
    ABSPacket *packet;
    callback_t callback;
  } task; 
  std::vector<std::thread> m_workers;
  std::vector<task> m_tasks;
};

[CheezBoiger]

@MichaelWallace30
I think this is what you want, if you think UAV or any of the plaforms are going to take advantage of our library threads,

https://en.wikipedia.org/wiki/Thread_pool

[MichaelWallace30]

I'll look into implementing the design because it's so easy to break and change my example.

[CheezBoiger]

yee, simply just have the threads continuously check the tasks data structure for anything they need to do, all the recv thread needs to do is give the packet and callback to the threadpool. My only concern at that point is that the error_t that returns from the callback will no longer affect what the recv thread will do with that packet, so it's up to each thread to know what they need to do after callback returns something like CALLBACK_DESTROY_PACKET.

[CheezBoiger]

It's either that or you make it explicit, and let the user deal with it, instead of telling the thread what they want to it to do.