Threading Summary

At the end of the 0.1 release, we noted threading issues as a possible snake: ThreadingIssueSummary. This page notes where we stand as we start work on the 0.3 release.

Overview

A typical Chandler desktop application will be composed of two processes: one running the GUI, another running the repository. For the purposes of this discussion, we'll refer to them as the GUI process and the repository process, although each process may have additional functionality (i.e. other middleware may run in the repository process, even though we don't consider it part of the repository proper). The repository process can be run as a daemon process without the GUI, so that other instances can communicate with the repository for sharing and other web services features. A kiosk version of Chandler might run only the GUI process.

• GUI Process
  • All GUI code (wxWindows/wxPython) will run in the main thread of the GUI process.
  • Any code that involves a long running task that could block or otherwise compromise the GUI response time should run in a separate "worker" thread. Examples:
    • Queries to the repository (talking to the repository process)
    • Fetching email
    • Fetching RSS data (e.g. ZaoBao)
    • Agents (these are already operating as separate worker threads)
  • User experience expected from long running tasks/worker threads:
    • Users should be able to stop long running tasks, if practical.
    • Users should get progressive feedback as it arrives (e.g. queries to the repository should start returning items as they arrive, not block until the entire query is finished).
    • Users should get feedback on the progress of long running tasks, if practical.
  • The worker threads need to be able to communicate with the GUI thread.
    • Worker threads cannot do any GUI work within the thread, including creating dialog boxes, updating windows, progress bars, etc. We need a mechanism for worker threads to queue up requests, where the GUI picks up these requests and acts on them. The Agent Framework, for example, has a simple mechanism for deferring actions to be executed by the main thread at idle time.
    • As python doesn't let one thread kill another, all "worker" threads needs to be designed to go away when asked. Agent threads already use this idiom.
  • It would be nice if programmers could easily write non-ui code that was meant to execute in a "worker" thread fairly easily, without having to write error prone code. ZaoBao is a good example. I think of it as being similar to writing servlets that run in an appserver: each servlet has its own thread, and can be largely unaware that its running in a multi-threaded environment. It would be great if each parcel writer didn't have to tackle hairy threading code. To make this happen, we're considering a "Worker Parcel" or "Action Parcel":
    • mechanism to load/unload the worker parcel, either on startup/shutdown or as a result of some event or condition.
    • api/mechanism to progressively update views that depend on the data
    • api/mechanism to update feedback ui: progress bars, etc.
    • api/mechanism to respond to requests to stop the worker thread.
  • We already have Agents as worker threads. We'll probably want to rationalize Agents and "worker parcels", perhaps reusing some elements.
  • The Notification Manager makes use of the Python Queue module, which facilitates communication between threads. The Notification Manager is one option for inter-thread communication.
  • Any data that the ui absolutely requires to function (that might block the ui) should be pre-loaded and accessible to the main thread. Basically, we don't want ui to ever fail on this data, because that absolutely prevents a good user experience.
  • The GUI process will contain a repository cache for fast repository access.
  • wxPython has several mechanisms for long running tasks, presumably we should be using threads and not the other options.

• Repository Process
  • Multiple processes may want to be communicating with a given repository, and the repository may create multiple threads to handle requests. Basically, we need to provide concurrent access to a shared repository.
  • The repository code needs to choose between two basic strategies, and live with the tradeoffs. The choice:
    • Lock shared resources, one must grab a lock before making changes. At the end of the day, this choice would likely result in some "locked" resources in read-only mode in the user interface.
    • No locks, notice conflicts when committing and throw them back to the application code. At the end of the day, this choice would likely result in the user being presented with a choice on how to resolve such conflicts.
  • We're choosing the second choice described above, being permissive about changes. Consequences:
    • The application/parcel writers are better off creating short, tight transactions to avoid conflicts. (This is likely better for undo, anyway)
    • We're going to need to more carefully design ui for conflict resolution.
  • Transactions are unique per thread, one cannot share transactions across threads.
  • As noted in the ThreadingIssueSummary, SMP (symmetric multi-processor machines) won't speed up a Python program. If we want to use threads to make the repository scalable on SMPs, we'll likely need to write that code in C.

• Two processes on the desktop
  • It may be the case that we'll want to optimize the communication between the two processes on a typical desktop application. We're going to take the strategy of handling this as a special optimization to the basic architecture of two processes.

0.3 Release To Do List

• Andi is tackling threading in the repository, in addition to transactions.
• We should tackle worker/action/task parcels, and rationalize them with similar Agent code.
• We should do code reviews of threading code, including: repository, agents, notification framework, worker parcels.

Resources

• http://www.python.org/doc/current/api/threads.html
• Chapter 6 (Threads, Processes, and Synchronization) of Python Cookbook
• Chapter 14 (Threads and Processes) of Python in a Nutshell
• Long Running Tasks on wxPyWiki
• Threading demo in wxPython demo
• Agent Framework

-- KatieCappsParlante - 06 Oct 2003