Post events from a thread to tango device server event loop

# 7 years ago
Andy	Hi Giacomo + Reynald, would a simple solution to Giacomo's problem not be to create a DeviceProxy and call read_attribute() from the background thread. This would take care of the conflicting accesses and avoid the need to create mutexes. This would be simulate the case of an external client. Just an idea. Cheers Andy

# 7 years ago
giacomo	Thanks Reynald, thanks Andy. Now it's clear to me Reynald, that's the answer I was looking for. Thanks Andy, this time I was looking for server side general tasks, not necessary involving Tango clients. See you soon! Giacomo

# 7 years ago
giacomo	Hello Reynald again. There are three possibilities to achieve my purpose now: 1. invoke a callback from my secondary thread(s) using tango monitor to get the lock. In this case the callback would be called from N different threads; 2. write an event loop, post the events from the N background threads to my custom event loop. Then acquire the monitor and invoke the callback from the custom event loop. This means the callbacks would be called by the thread where the custom event loop lives (only one thread). The custom event loop should be installed with tg util set_server_loop(). 3. "awaken" the ORB event loop so that messages are popped from a queue and process in the same thread as, let's say, where MuDeviceImpl::read_double_scalar's. Is solution 3 easily achievable? What do you think is best between 1 and 2, if 3 not possible? We can of course have a chat tomorrow. Have a good evening. Giacomo

# 7 years ago

giacomo

Hello Reynald again.

There are three possibilities to achieve my purpose now:
1. invoke a callback from my secondary thread(s) using tango monitor to get the lock.
In this case the callback would be called from N different threads;
2. write an event loop, post the events from the N background threads to my custom event loop. Then acquire the monitor and invoke the callback from the custom event loop. This means the callbacks would be called by the thread where the custom event loop lives (only one thread). The custom event loop should be installed with tg util set_server_loop().
3. "awaken" the ORB event loop so that messages are popped from a queue and process in the same thread as, let's say, where MuDeviceImpl::read_double_scalar's.

Is solution 3 easily achievable?
What do you think is best between 1 and 2, if 3 not possible?

We can of course have a chat tomorrow.

Have a good evening.
Giacomo

# 7 years ago
giacomo	Hello Reynald, I realise that point 3 does not make sense. Maybe yesterday at 6pm I was tired… I will go for implementation in point 2. Thanks for Your support. Have a good day. Giacomo.

# 7 years ago
Reynald	Please note that if you use the possibility 2, the event loop function passed to server_set_event_loop() will be executed in a loop once every 20 ms at the maximum… Looking at the Util::server_perform_work() method which is called at some point from the main thread might help you to better understand how is handled the custom event loop feature: https://github.com/tango-controls/cppTango/blob/tango-9-lts/cppapi/server/utils.cpp#L1921 If you need something more reactive than 20ms, you should change the Tango source code or use another solution. Cheers, Reynald Rosenberg's Law: Software is easy to make, except when you want it to do something new. Corollary: The only software that's worth making is software that does something new.

# 7 years ago

Reynald

Please note that if you use the possibility 2, the event loop function passed to server_set_event_loop() will be executed in a loop once every 20 ms at the maximum…
Looking at the Util::server_perform_work() method which is called at some point from the main thread might help you to better understand how is handled the custom event loop feature: https://github.com/tango-controls/cppTango/blob/tango-9-lts/cppapi/server/utils.cpp#L1921

If you need something more reactive than 20ms, you should change the Tango source code or use another solution.
Cheers,
Reynald

Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.