TCL script with multithreading

[sebastian.johansson]

Hello,

I have the need to run multiple tasks simultaneously within my TCL script. The thing I want to accomplish is that when an ethernet cable is unplugged, something should happen. To make it somewhat easier, let's say that an output should be printed after 30 seconds saying that the cable have been unplugged. I am using event_register_neighbor_discovery and listening for line-event down to trigger the script. The thing is that i want to monitor more than one interface, let's say 3 different interfaces.

I can solve this by executing my tasks serially, but if another interface gets unplugged within the wait-period for another interface, the script waits for the tasks triggered by the first interface getting unplugged before it takes care of the second. I want this to happen parallelized. Is this possible?

I paste the small example I have been scratching together so far below.

::cisco::eem::event_register_neighbor_discovery tag if_1 interface GigabitEthernet0/9 line-event down maxrun 60

::cisco::eem::event_register_neighbor_discovery tag if_2 interface GigabitEthernet0/10 line-event down

::cisco::eem::event_register_neighbor_discovery tag if_2 interface GigabitEthernet0/10 line-event down

::cisco::eem::trigger {

::cisco::eem::correlate event if_1 or event if_2

}

namespace import ::cisco::eem::*

namespace import ::cisco::lib::*

array set arr_einfo [event_reqinfo]

set interface $arr_einfo(local_intf_name)

puts stdout "Script initiated for interface $interface"

after 30000

puts stdout "Interface $interface have been unplugged"

Thanks in advance

Regards Sebastian

[Joe Clarke · Accepted solution]

You can increase the number of parallel script threads using the command:

event manager scheduler script thread class default number X

Where X is the desired number of threads.  The default is 1.  You will likely want 3.

Note: your script won't work the way you want.  The puts messages will be sent as syslogs as opposed to being printed on a TTY line.  This is because the script runs asynchronously with no controlling terminal.

Another thing you might consider is having this Tcl policy configure an applet policy that counts down 30 seconds then sends the message.  This way, you immediately yield the queue, and wouldn't need more script threads.  Each applet could be named for the "down" interface, so multiple applets could exist at the same time.

[sebastian.johansson]

Thank you!

I solved my problem by using the method with letting the TCL script create EEM applets, like you suggested. It works like a charm.

Regards

Sebastian