@charlesrchance - a solution is to use a shared memory variable to say if something needs
to be consumed, like:
```
// mod init
int *dmq_usrloc_tasks = shm_malloc(sizeof(int));
*dmq_usrloc_tasks = 0;
gen_lock_t *dmq_usrloc_tasks_lock = ... // usual lock initialization
// runtime - producer
lock_get(dmq_usrloc_tasks_lock);
*dmq_usrloc_tasks++
lock_release(dmq_usrloc_tasks_lock);
// runtime - consumer
while (1) {
lock_get(dmq_usrloc_tasks_lock);
while(*dmq_usrloc_tasks>0) *dmq_usrloc_tasks++;
lock_release(dmq_usrloc_tasks_lock);
sleep_us(dmq_usrloc_tasks_sleep);
}
```
The incrementing/decrementing needs to be accompanied by producing/consuming the tasks.
The key here is the sleep_us(), where dmq_usrloc_tasks_sleep can be a new mod param to
specify the miliseconds (or microseconds) to sleep. It proved that triggering a sleep
takes the cpu from process and cpu load is kept low. One can tune its value to suit better
its environment.
IIRC, this is used by maybe in async module for async_route().
An alternative is using in-memory sockets to pass tasks from producers to consumers. The
consumer should be blocked in a read() and that should not consume cpu, although on some
systems I got read() returning fast with error, ending in a loop of fast reads and high
cpu again. This should be used by evapi to pass events between sip workers and evapi
worker.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/822#issuecomment-258382642