Many thanks, I'll look into it. Tim
-----Message d'origine----- De : Yusuke Iwase [mailto:[email protected]] Envoyé : vendredi 23 octobre 2015 09:17 À : Tim LEGRAND Cc : [email protected]; [email protected] Objet : Re: [Ryu-devel] Events handling parallelization in Ryu Applications Hi, > First question: “is Ryu’s call to event_catcher(ev) itself already > asynchronous?” As far as I know, the answer for this question is 'No' against 'each event'. Ryu raises events (e.g. EventOFPPacketIn) asynchronously, but sequentially invokes the event handlers which '@set_ev_cls(...)' decorated method for each event. For example... When Ryu raises event.Foo, _Foo_event_handler_in_B will not be called until _Foo_event_handler_in_A is done, but if event.Ber occurs, _Ber_event_handler_in_A may be invoked regardless of _Foo_event_handler_in_A is done or not. class RyuAppA(app_manager.RyuApp): @set_ev_cls(event.Foo) def _Foo_event_handler_in_A(ev): ... @set_ev_cls(event.Ber) def _Ber_event_handler_in_A(ev): ... class RyuAppB(app_manager.RyuApp): @set_ev_cls(event.Foo) def _Foo_event_handler_in_B(ev): ... If you want to call self.WorkOn(ev.msg) asynchronously, how about using ryu.lib.hub.spawn function? spawn (or spawn_after) invokes the new thread. e.g.) from ryu.lib import hub ... @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER) def event_catcher(self, ev): hub.spawn(self.WorkOn, ev.msg) Thanks, Iwase On 2015年10月23日 01:51, Yi Tseng wrote: > Hi > > According to ryu source code: > > When ryu receive a message from switch, it will push it to a queue, and pop > the message from here: > > https://github.com/osrg/ryu/blob/master/ryu/base/app_manager.py#L271 > > and application will call event handlers. (And it might be block) > > To avoid blocking, we can add timeout to event handlers, for example: > > https://github.com/TakeshiTseng/ryu/commit/aa75f116111239ecba6b49601f0 > c6ad5e54aace3 > > However, it's not safe to terminate one handler if we don't have any rollback > mechanism. > > > > > 2015-10-22 17:45 GMT+08:00 Tim LEGRAND <[email protected] > <mailto:[email protected]>>: > > Hello folks,____ > > __ __ > > I am quite new to Ryu (but not to Python nor threading), so > forgive me in advance if I’m mistaken with something.____ > > __ __ > > My Ryu application subscribes to Ryu’s events using :____ > > __ __ > > @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER)____ > > def event_catcher(self, ev):____ > > self.WorkOn(ev.msg)____ > > __ __ > > What I want to achieve is getting this last function call > (self.WorkOn(ev.msg)) running asynchronously, and concurrently(1)(2), > so that other events that could be raised and handled while the first > one is processing. My first try would be to use green-threads to > handle such events.____ > > __ __ > > First question: “is Ryu’s call to event_catcher(ev) itself already > asynchronous?”____ > > __ __ > > __è __Case 1: If yes, I guess that asynchronism is obtained with > a green-thread. Does it make /creating a new green-thread dedicated to > its body/ redundant?____ > > __è __Case 2: If no, I guess that events are blocking, so the Ryu > Application is not able to receive simultaneous events, so it would be > interesting to make the body’s function asynchronous. Am I right?____ > > __ __ > > (I know that there’s a dedicated thread in Ryu Applications > working as an event-loop listener - see > https://osrg.github.io/ryu-book/en/html/arch.html#application-programm > ing-model, but what I can’t figure out is if the events are raised > asynchronously or not)____ > > __ __ > > If no (Case 2): “Am I able to use green-threads to implement > asynchronism in the events handling?”____ > > __ __ > > I am asking because I’ve read that “While threads and queues is > currently implemented with eventlet/greenlet, a direct use of them in > a Ryu application is strongly discouraged.”____ > > Why is that? In what manner my greenlet coroutines would affect > Ryu’s ones?____ > > __ __ > > Thanks for your time!____ > > Tim____ > > __ __ > > (1) and ideally /in parallel/ but Python has its own drawbacks > about parallelism depending on the Python implementation used (GIL or > not), and it is not the purpose of my question here____ > > (2) be sure not to confuse between concurrency and parallelism: > concurrency is the /ability/ to run in parallel, parallelism is about > to use several CPU cores at the same time.____ > > __ __ > > *__ __* > > > > ---------------------------------------------------------------------- > -------- > > _______________________________________________ > Ryu-devel mailing list > [email protected] <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/ryu-devel > > > > > -- > Yi Tseng (a.k.a Takeshi) > Taiwan National Chiao Tung University > Department of Computer Science > W2CNLab > > http://blog.takeshi.tw > > > ---------------------------------------------------------------------- > -------- > > > > _______________________________________________ > Ryu-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ryu-devel > ------------------------------------------------------------------------------ _______________________________________________ Ryu-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ryu-devel
