Thank you Iwase. I was actually thinking in using queues to synchronise information between Ryu's threads and native threads, since I'm also using Pyro4 to communicate with another service. But my doubt here is, how can I suspend a Ryu thread and make it wait for a message to arrive at a queue? I have never used ZeroMQ and I wanted to use a simple mechanism, like the native Python queue.Queue, for example.
Carlos On 20 December 2017 at 23:45, Iwase Yusuke <iwase.yusu...@gmail.com> wrote: > Hi Carlos, > > Please let me confirm your issue first. > Your question is how to suspend the current thread waiting for some works > finished (REST request? or other thread?), right? > To suspend your threads using ryu.lib.hub.spawn, you can use > "eventlet.event" > which is similar to a Queue or threading.Lock. > http://eventlet.net/doc/modules/event.html > > For example: > > Ryu xxx_handler thread worker > | Event | | | > |------>| | | > | | hub.spawn | | > | |---------->| | > | | | request some | > | | |------------->| > | | | response | > | | FlowMod |<-------------| > | | request | | > |<------------------| | > | | | | > > > On this situation, your problem is mixing the Native Threads and the > GreenThreads? > As far as I know, the Native Threads behave (normally) as IO blocking > threads > and Ryu's threads (using ryu.lib.hub.spawn) behave as non-blocking threads. > Generally, it is not recommended to mix blocking and non-blocking in the > same > process, if these need to cooperate, I guess some APIs like socket (TCP, > REST or > so), file, messaging queue(http://eventlet.net/doc/zeromq.html) is better > way to > communicate between blocking and non-blocking. > > Does someone know more better way? > > > Thanks, > Iwase > > > > On 2017年12月20日 07:52, Carlos Ferreira wrote: >> >> Iwase, can you help me here, please? >> >> Thank you! >> >> Carlos Ferreira >> >> On 18 December 2017 at 11:16, Carlos Ferreira <carlosmf...@gmail.com> >> wrote: >>> >>> Hmm, suspending all Ryu activities that is precisely what I was trying to >>> avoid. >>> >>> Ok I have another idea. Instead of having the coroutine waiting for >>> some work to be processed, what if I have a Python thread creating a >>> new coroutine using ryu.lib.hub.spawn, which will then active the >>> necessary flows when a decision is ready to be implemented? >>> >>> I had issues in the past, when mixing Threads and the greenlet >>> coroutines, having problems when sharing information between them. >>> >>> Thank you Iwase, for your help! >>> >>> >>> On 18 December 2017 at 05:39, Iwase Yusuke <iwase.yusu...@gmail.com> >>> wrote: >>>> >>>> Hi Carlos, >>>> >>>> Well, as far as I know, Ryu does not provides the features for >>>> suspending >>>> the >>>> specific activities (e.g., threads) of Ryu, so I guess you can only >>>> suspend >>>> all activities at the same time. >>>> >>>> Just an idea, the following suspends all Ryu activities when calling >>>> sleep() >>>> and prevents other threads getting executed. >>>> The following uses the "non-patched" time module to suspend greanthread. >>>> If you need some locks, please use threading.Lock instead of >>>> time.sleep(). >>>> >>>> >>>> $ git diff >>>> diff --git a/ryu/app/simple_switch_13.py b/ryu/app/simple_switch_13.py >>>> index 06a5d0e..316ee37 100644 >>>> --- a/ryu/app/simple_switch_13.py >>>> +++ b/ryu/app/simple_switch_13.py >>>> @@ -22,6 +22,9 @@ from ryu.lib.packet import packet >>>> from ryu.lib.packet import ethernet >>>> from ryu.lib.packet import ether_types >>>> >>>> +from eventlet import patcher >>>> +orig_time = patcher.original('time') >>>> + >>>> >>>> class SimpleSwitch13(app_manager.RyuApp): >>>> OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION] >>>> @@ -29,6 +32,7 @@ class SimpleSwitch13(app_manager.RyuApp): >>>> def __init__(self, *args, **kwargs): >>>> super(SimpleSwitch13, self).__init__(*args, **kwargs) >>>> self.mac_to_port = {} >>>> + self.is_something_done = False >>>> >>>> @set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER) >>>> def switch_features_handler(self, ev): >>>> @@ -63,8 +67,19 @@ class SimpleSwitch13(app_manager.RyuApp): >>>> match=match, instructions=inst) >>>> datapath.send_msg(mod) >>>> >>>> + def _do_something_with_global_blocking(self): >>>> + if self.is_something_done: >>>> + return >>>> + >>>> + self.logger.info('waiting for done of something...') >>>> + orig_time.sleep(10) >>>> + self.is_something_done = True >>>> + self.logger.info('done.') >>>> + >>>> @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER) >>>> def _packet_in_handler(self, ev): >>>> + self._do_something_with_global_blocking() >>>> + >>>> # If you hit this you might want to increase >>>> # the "miss_send_length" of your switch >>>> if ev.msg.msg_len < ev.msg.total_len: >>>> >>>> >>>> With the above modification, simple_switch_13.py blocks all Ryu >>>> activities >>>> while >>>> 10 seconds, and Packet-In event will not be handled until done. >>>> >>>> $ ryu-manager ryu/app/simple_switch_13.py >>>> loading app ryu/app/simple_switch_13.py >>>> loading app ryu.controller.ofp_handler >>>> instantiating app ryu/app/simple_switch_13.py of SimpleSwitch13 >>>> instantiating app ryu.controller.ofp_handler of OFPHandler >>>> waiting for done of something... >>>> done. >>>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1 >>>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1 >>>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1 >>>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1 >>>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1 >>>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1 >>>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1 >>>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1 >>>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1 >>>> packet in 1 82:3d:bb:d5:d6:ba c2:09:7b:d2:6c:a2 2 >>>> packet in 1 c2:09:7b:d2:6c:a2 82:3d:bb:d5:d6:ba 1 >>>> packet in 1 c2:09:7b:d2:6c:a2 82:3d:bb:d5:d6:ba 1 >>>> ...(snip)... >>>> >>>> mininet> h1 ping h2 >>>> PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. >>>> From 10.0.0.1 icmp_seq=1 Destination Host Unreachable # not handled as >>>> sleeping >>>> From 10.0.0.1 icmp_seq=2 Destination Host Unreachable >>>> From 10.0.0.1 icmp_seq=3 Destination Host Unreachable >>>> From 10.0.0.1 icmp_seq=4 Destination Host Unreachable >>>> From 10.0.0.1 icmp_seq=5 Destination Host Unreachable >>>> From 10.0.0.1 icmp_seq=6 Destination Host Unreachable >>>> From 10.0.0.1 icmp_seq=7 Destination Host Unreachable >>>> From 10.0.0.1 icmp_seq=8 Destination Host Unreachable >>>> From 10.0.0.1 icmp_seq=9 Destination Host Unreachable >>>> 64 bytes from 10.0.0.2: icmp_seq=10 ttl=64 time=2005 ms >>>> 64 bytes from 10.0.0.2: icmp_seq=11 ttl=64 time=996 ms >>>> 64 bytes from 10.0.0.2: icmp_seq=12 ttl=64 time=0.170 ms >>>> 64 bytes from 10.0.0.2: icmp_seq=13 ttl=64 time=0.055 ms >>>> 64 bytes from 10.0.0.2: icmp_seq=14 ttl=64 time=0.059 ms >>>> 64 bytes from 10.0.0.2: icmp_seq=15 ttl=64 time=0.066 ms >>>> ^C >>>> --- 10.0.0.2 ping statistics --- >>>> 15 packets transmitted, 6 received, +9 errors, 60% packet loss, time >>>> 14054ms >>>> rtt min/avg/max/mdev = 0.055/500.491/2005.751/765.266 ms, pipe 3 >>>> >>>> >>>> Please note that this approach will suspend "all" activities of Ryu, if >>>> a >>>> lot of >>>> Packet-In events curred while blocking, these event will invoked >>>> immediately. >>>> >>>> >>>> Thanks, >>>> Iwase >>>> >>>> >>>> >>>> On 2017年12月15日 06:03, Carlos Ferreira wrote: >>>>> >>>>> >>>>> I work with real switches (Zodiac FX). >>>>> >>>>> Depending on the Events, wether is Packet_In or other Events, I want >>>>> to take different kinds of actions. >>>>> Some of these actions, require contacting a different system >>>>> component, outside of the Ryu scope. >>>>> What I want, is to have a way to suspend the greenlet execution and >>>>> continue with the following Events processing, while the outside >>>>> system does its thing. Once the outside system returns with the >>>>> required data, the greenlet will resume the processing. >>>>> >>>>> Carlos >>>>> >>>>> >>>>> On 14 December 2017 at 20:37, <marcosab...@inf.ufg.br> wrote: >>>>>> >>>>>> >>>>>> When you subscribe an event (with @override) while switch is connect >>>>>> you >>>>>> receive this event. You can ignore these events implementing a logic >>>>>> according your application. But when you ignore an event, for exemple >>>>>> Packet_IN, you loss the packets that enter in switch. >>>>>> >>>>>> Can you explain more your problem? You work with real switch or OVS? >>>>>> >>>>>> Citando Carlos Ferreira <carlosmf...@gmail.com>: >>>>>> >>>>>>> Hello to all! >>>>>>> >>>>>>> Is it possible to suspend a Ryu Coroutine event? For example, suspend >>>>>>> the execution of the Packet_IN handler, while waiting for an event, >>>>>>> signal or condition? >>>>>>> >>>>>>> I need to know how can I do this, because I need to execute some >>>>>>> algorithms, which may take some time and depend upon resources >>>>>>> outside >>>>>>> of the application. I wanted for the coroutine to wait until it gets >>>>>>> a >>>>>>> result, but I didn't want to stall the entire event pipeline. >>>>>>> >>>>>>> Thank you! >>>>>>> Carlos Ferreira >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> Check out the vibrant tech community on one of the world's most >>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>>>>> _______________________________________________ >>>>>>> Ryu-devel mailing list >>>>>>> Ryu-devel@lists.sourceforge.net >>>>>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Check out the vibrant tech community on one of the world's most >>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>>>> _______________________________________________ >>>>>> Ryu-devel mailing list >>>>>> Ryu-devel@lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Check out the vibrant tech community on one of the world's most >>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>>> _______________________________________________ >>>>> Ryu-devel mailing list >>>>> Ryu-devel@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel >>>>> >>>> >>> >>> >>> >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Ryu-devel mailing list >> Ryu-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/ryu-devel >> > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Ryu-devel mailing list Ryu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ryu-devel
