Develop
Ticket #960 (closed defect: fixed)
Create way to suspend threads while waypoint database is updated
| Reported by: | RobD | Owned by: | max |
|---|---|---|---|
| Priority: | normal | Milestone: | XCSoar 6.1 |
| Component: | Waypoints | Version: | 6.0 |
| Keywords: | waypoints | Cc: |
Description
Purpose: to suspend the other threads cheaply, without actually stopping them.
Discussion leading up to this purpose:
<cirrus> Waypoints are never locked. each time the object is edited, all threads are suspended.
<jmw> does that happen there in dlgTaskManager?
<cirrus> no. that's bugged.
<cirrus> hmmm, this shouldn't be done in the calculation thread.
<jmw> where then?
<cirrus> current (undocumented) policy is: Waypoints may only be edited in the main thread, with all other threads suspended.
<cirrus> since the main thread cannot be suspended, we cannot move that to another thread.
<cirrus> we could add a lock for Waypoints, but at some point I decided we don't need that, because modifications are extremely rare, and we can save the overhead.
<cirrus> ProcessTimer? would be the right location. there we have a takeoff trigger already.
<jmw> oh bugger. that's a problem then because if that code i added then was moved into main, we can't be sure it gets called immediately before the task->update() which itself triggers the check goto.
<jmw> oh ok.
<cirrus> why not move the goto thing to ProcessTimer?, too?
<cirrus> the calculation thread should only calculate, but never modify the task
<RobD1> there are two other places that need to alter the waypoints:
<jmw> maybe then we have to explicitly call into the TaskManager?.cpp:275 line rather than having that done in the TaskManager::update()
<RobD1> 1) when starting XCSoar, we load the DEFAULT task.
<RobD1> 2) when altering the waypoints file (of course) but we need to also call the dedupe waypoints there too.
<cirrus> could one of you two please create a ticket? I will write some way to suspend the other threads cheaply, without actually stopping them.
<jmw> cirrus: move goto into processtimer, yes, that's what i mean. you can see the call that needs to be made.

There is SuspendAllThreads?() and ResumeAllThreads?(). The only remaining problem is that it is not safe, it is not guarantee that the threads are really suspended when SuspendAllThreads?() returns.