View Issue Details

IDProjectCategoryView StatusLast Update
0002172CCdciel[All Projects] Generalpublic19-08-27 15:42
ReporterCedric RaguenaudAssigned ToPatrick Chevalley 
PrioritynormalSeverityminorReproducibilityhave not tried
Status resolvedResolutionfixed 
Product Version 
Target Version1.0Fixed in Version 
Summary0002172: Suggestion: data collecting jobs in their own thread
DescriptionIt would be good if tasks that are orthogonal to the functioning of ccdciel ran in their own thread so as to not lock ccdciel while they wait to complete, e.g. Safety and weather monitors.
TagsNo tags attached.


Patrick Chevalley

19-08-25 11:22

administrator   ~0005874

Can you give more information about function that lock ccdciel? if possible with a log so I can try to reproduce the situation with the simulator.

I just tested with a sequence interrupted by bad weather with message "Sequence paused for bad weather ...".
In this case the interface is not locked, you can click any menu and you can use the sequence Stop button to terminate.

Cedric Raguenaud

19-08-25 11:31

reporter   ~0005876

It happened to me when my safety monitor, which loads external data (weather), couldn't reach its source of information (network issue). Then ccdciel was locked until the timeout in the network connection within the safety monitor was reached. At least I think that's wat was happening. I see nothing specific in the logs.

Patrick Chevalley

19-08-25 12:14

administrator   ~0005877

OK, I understand.

CCDciel make every ASCOM call from the main thread because many ASCOM driver are not thread safe.
For this monitoring ccdciel use a timer to check the device status periodically, in this case it call IsSafe from the main thread.

In this case the safetymonitor interface is so simple with this unique function that I can try to make the check in a separate thread. For more complex driver I have to use some lock (mutex) to prevent simultaneous call and this can introduce other problem.

Cedric Raguenaud

19-08-25 12:24

reporter   ~0005878

I see what you mean. I solved the problem in my case by moving the data fetch to a raspberry pi which does some caching so that when the safety driver requests the data it never had to wait.
But this could happen for example if someone uses online weather data to feed their safety monitor (do people do that? I think it's the default for NINA and Ekos).

Patrick Chevalley

19-08-25 13:04

administrator   ~0005879

Yes I think this is the good way. Probably the driver must do it's periodic data collection and when IsSafe is called it only have to check the available data.
I don't know of online weather ascom driver, but the indi driver do the data collection independently of reporting the status. This is also because online weather server do not change too often and the number of daily api call is limited.
Also this issue is not possible with indi because ccdciel never make a query to the driver, it is the driver that send a message when the status change.

I make a change to the program to prevent flooding by timer event in the case the query function take more time than the timer interval. I have already do that for the Alpaca interface but local ascom was not protected again this issue:

Patrick Chevalley

19-08-27 15:42

administrator   ~0005888

I think this change is all I can do to help in such case.

From the ASCOM basic principle It is really to the driver to handle any communication issue with the hardware, maintain a cache of data that are slow to access, or decide what to do if the data are not available.

In the case an exception is raised, ccdciel assume unsafe status.

Issue History

Date Modified Username Field Change
19-08-24 04:13 Cedric Raguenaud New Issue
19-08-24 10:13 Patrick Chevalley Assigned To => Patrick Chevalley
19-08-24 10:13 Patrick Chevalley Status new => assigned
19-08-24 10:13 Patrick Chevalley Target Version => 1.0
19-08-25 11:22 Patrick Chevalley Status assigned => feedback
19-08-25 11:22 Patrick Chevalley Note Added: 0005874
19-08-25 11:31 Cedric Raguenaud Note Added: 0005876
19-08-25 11:31 Cedric Raguenaud Status feedback => assigned
19-08-25 12:14 Patrick Chevalley Note Added: 0005877
19-08-25 12:24 Cedric Raguenaud Note Added: 0005878
19-08-25 13:04 Patrick Chevalley Note Added: 0005879
19-08-27 15:42 Patrick Chevalley Status assigned => resolved
19-08-27 15:42 Patrick Chevalley Resolution open => fixed
19-08-27 15:42 Patrick Chevalley Note Added: 0005888