AudioManager  7.5.11
Native Application Runtime Environment
 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Macros Pages
Mainloop concept

Mainloop

The AudioManager comes with a build in mainloop that can be utilized by the plug-ins to serve their needs of communication and thread-safe calling. The mainloop, implemented in CAmSocketHandler works like this:

Mainloop.png

Using the Mainloop

Adding and removing callbacks and timers work via the am::CAmSocketHandler.
To add a callback, use am::CAmSocketHandler::addFDPoll, to remove one, use am::CAmSocketHandler::removeFDPoll.
To add a timer callback, use am::CAmSocketHandler::addTimer, use am::CAmSocketHandler::removeTimer and am::CAmSocketHandler::restartTimer and am::CAmSocketHandler::stopTimer.
The mainloop is started via am::CAmSocketHandler::start_listenting and stopped via am::CAmSocketHandler::stop_listening. Example code can be found in am::CAmDbusWrapper.

Utilizing The Mainloop as Threadsafe Call Method

The AudioManager itself is singlethreaded, so any calls from other threads inside the plugins directly to the interfaces is forbidden, the behavior is undefined. The reason for this is that communication and routing plugins are often only communication interfaces that can are ideally used with the am::CAmSocketHandler.
am::CAmSerializer creates an intermediate object on the heap holding all informations of the function to be called and a pointer to the object to be called. After that, the class writes to a pipe witch triggers the mainloop to call the callback am::CAmSerializer::receiverCallback from the maincontext. The callback uses the intermediate object to do the actual call.

Warning
asynchronous calls can be used within the main thread, but synchronous not -> the call would block forever !
For each thread that needs to use synchronous calls independent an own instance of am::CAmSerializer needs to be used.

Asynchronous calls

Deferred_Call_async.png

Synchronous calls

Deferred_Call_sync.png