[SR-Users] async workers

[Alex Balashov]

Thanks, Daniel. So, does this mean that the module "reserves" a "workers" number of common async_workers for its exclusive use? Or do those async_workers just receive whatever they are sent from any number of modules? In that case, what exactly is the role of the "workers" parameter? To limit the number of async_workers to which the module will send requests? 


On 24 October 2014 09:15:19 GMT-04:00, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
>
>On 23/10/14 04:03, Alex Balashov wrote:
>> Also, what is the point of core async_workers setting versus the
>> 'workers' modparam to async? Are they supposed to equal each other?
>> Does one override the other?
>
>async_workers from core are common for all modules, being a decision
>not
>to have each module that wants async operations to create its own pool
>of processes. The workers defined by async module are only for that
>module and used only by async_route() and async_sleep().
>
>The implementation is also different, the async module workers are more
>like timer processes (because both of async_route() and async_sleep()
>need to sleep some interval of time). The module itself keeps the lists
>of tasks in a structure optimized for timer execution. Each of this
>async module workers check from time to time to see if there is a task
>to be executed, executes what matches the time, then sleeps again for
>100ms (iirc), then checks again...
>
>The async_workers from core were designed to receive the job
>immediately. Because of that, there is an interprocess communication
>based on sockets in memory. The async workers are listening on them, so
>once a sip worker sends the task to them, an async worker will receive
>it.
>
>Hopefully I was able to explain it enough to understand what happens
>behind.
>
>Cheers,
>Daniel
>>
>> On 10/22/2014 09:36 PM, Alex Balashov wrote:
>>
>>> Hi,
>>>
>>> What is the practical limit to the number of async worker processes?
>>>
>>> With SIP child processes, it seems to be about the number of
>available
>>> CPUs in /proc/cpuinfo. After that--at least, per my testing--one
>begins
>>> to hit the point of diminishing returns, presumably due to SHM IPC
>and
>>> synchronisation issues.
>>>
>>> Is the restriction similar in the async execution context?
>>>
>>
>>

--
Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard. 

Alex Balashov - Principal 
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0671
Web: http://www.evaristesys.com/, http://www.alexbalashov.com