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/aa75f116111239ecba6b49601f0c6ad5e54aace3
>
> 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-programming-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
