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 _______________________________________________ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
