[OpenSIPS-Devel] RFC: new opensips design

Bogdan-Andrei Iancu bogdan at voice-system.ro
Mon Nov 10 18:46:47 CET 2008


Dan Pascu wrote:
> On Friday 07 November 2008, Bogdan-Andrei Iancu wrote:
>   
>> Just to give an example: let's assume we have 1 process
>>
>> 1) current design:
>>     time T - a message is read from network
>>     t+1 - a DB is invoked
>>        ---- idle ------
>>     t+3 - reply from DB
>>     t+4 - done with the message
>>     t+5 - read the next one
>>
>> 2) new design
>>     time T - a message is read from network (reactor gets indication
>> from the network socket)
>>     t+1 - a DB is invoked (context is suspended and a new socket is
>> added to the reactor for waiting the DB reply)
>>     t+2 - a second message is read from network (reactor gets again
>> indication from the network socket)
>>     t+3 - second message is done
>>     t+4 - reply from DB (reactor get indication from the DB socket) -
>> context is restored for the first message
>>     t+5 - done with the first message
>>     
>
> While this is a good example to show how things work, I have to make 2 
> comments:
>
> 1. I know of no asynchronous database API, so in real life this cannot be 
> applied to a database connection. Other mechanisms need to be employed 
> with them.
>   
I totally agree - this will be one of the challenges  - to transform all 
the synchronous I/Os we have now is async ones ...
> 2. Context switching is completely unnecessary, as long as the message you 
> process is embodied in an object/structure that contains all the relevant 
> information about that message. When an event happens and you get a 
> notification and the associated object you just operate on it. The 
> classical context switching that is necessary with multithreading or 
> system processes it not needed here.
>   
By context switching I was refering to the switching (inside the same 
thread/process) to a different SIP message to be processed (and its 
context) - not thread/process switching.

Regards,
Bogdan




More information about the Devel mailing list