QTango and asynchronous command execution

# 7 years ago
t-b	Hi, I'm using QTango as GUI for my tango servers. And one of my tango servers performs a long running command (converting data from format A to format B). This triggers the default timeout of three seconds and results in a popup in the GUI. Now I can of course hack that to work as in — a/gui/qtango/trunk/qtangocore/src/taction.cpp +++ b/gui/qtango/trunk/qtangocore/src/taction.cpp @@ -451,6 +451,11 @@ TVariant& TAction::execute(QVariant v, bool push) } else if(d_type == COMMAND) { + // @todo HACK! increase the timeout to 5 minutes, required for device + // servers like XXX + // need to make this configurable via properties like startDSPath of TangoStarter + d_device->set_timeout_millis(1000 * 60 * 5); + /* no need to lock d_cmdInfo, d_argin, d_stdPoint: they are not concurrently modified */ if(v.isNull()) { but this is kind of ugly. Is there a better fix for that which I missed? An additional problem with this long running command is that other GUI controls referencing the same device server, for example the Status command/attribute, don't get updated and fail with a timeout. My research indicates that this happens with both "synchronous" and "asynchrounous" execution mode, as in both cases we only have either the GUI thread executing the command or the device thread. Is it possible to have multiple device threads for one device? Or other workarounds? Thanks, Thomas

# 7 years ago

Hi,

I'm using QTango as GUI for my tango servers. And one of my tango servers performs a long running command (converting data from format A to format B). This triggers the default timeout of three seconds and results in a popup in the GUI.

Now I can of course hack that to work as in


— a/gui/qtango/trunk/qtangocore/src/taction.cpp
+++ b/gui/qtango/trunk/qtangocore/src/taction.cpp
@@ -451,6 +451,11 @@ TVariant& TAction::execute(QVariant v, bool push)
         }
         else if(d_type == COMMAND)
         {
+            // @todo HACK! increase the timeout to 5 minutes, required for device
+            // servers like XXX
+            // need to make this configurable via properties like startDSPath of TangoStarter
+            d_device->set_timeout_millis(1000 * 60 * 5);
+
             /* no need to lock d_cmdInfo, d_argin, d_stdPoint: they are not concurrently modified */
             if(v.isNull())
             {

but this is kind of ugly. Is there a better fix for that which I missed?

An additional problem with this long running command is that other GUI controls referencing the same device server, for example the Status command/attribute, don't get updated and fail with a timeout. My research indicates that this happens with both "synchronous" and "asynchrounous" execution mode, as in both cases we only have either the GUI thread executing the command or the device thread. Is it possible to have multiple device threads for one device? Or other workarounds?

Thanks,
Thomas

# 7 years ago
nleclercq	Hey Thomas, In Tango, 'asynchronous' is a pure client concept. Everything is synchronous on server side. Moreover, unless you totally disable the device monitor (i.e. mutex), you can have only one thread managing the external requests. Disabling the device monitor is generally not a good idea (unless you device is written to handle such a context). One possible solution for your case would be to implement some kind of 'future mechanism' in your device. You could spawn a thread managing your 'long running command' and add a command (or attribute) to your device to retrieve the result. It would also be a good idea to change the device State while the 'long running command' is in progress so that the device's state machine can prevent other actions to be performed. Have a look to the yat4tango::Task. It could make sense here. Hope this help, N. Edited 7 years ago

# 7 years ago

nleclercq

Hey Thomas,

In Tango, 'asynchronous' is a pure client concept. Everything is synchronous on server side. Moreover, unless you totally disable the device monitor (i.e. mutex), you can have only one thread managing the external requests. Disabling the device monitor is generally not a good idea (unless you device is written to handle such a context).

One possible solution for your case would be to implement some kind of 'future mechanism' in your device. You could spawn a thread managing your 'long running command' and add a command (or attribute) to your device to retrieve the result. It would also be a good idea to change the device State while the 'long running command' is in progress so that the device's state machine can prevent other actions to be performed. Have a look to the yat4tango::Task. It could make sense here.

Hope this help,
N.

Edited 7 years ago

# 7 years ago
t-b	Thanks Nicolas for the explanation. My device servers use the default serialization model ("Serialization by device") so your explanation makes totally sense. I guess I have to use something like the "future mechanism".