I find it unfortunate that a common perception is that threads are a good approach to this problem. While this does work, this approach to threading makes you dance around locking issues just like this article describes.
A better way to handle GUI updates is to use an asynchronous approach. That is, tasks that do IO should use asynchronous IO so that the GUI can remain responsive while something is happening. Tasks that require long computations should launch threads _as workers_ that will come back with an answer. The GUI thread should not wait on these threads by launch them as asynchronous services, and provide a function or message handler that will be called when the task is complete rather than waiting around for an answer. This works just as well by talking to another _process_ instead of a thread, and then you can use IPC methods for communication to ensure safety. Using sockets for communication between processes can even be used in an asynchronous (non-blocking) manner, which might provide _better_ performance than what you would get from copious use of threads and the accompanying sync locking.
Another approach is not to launch threads at all but instead break up the computational loop into several callbacks of a timer, or idle function. This is a way to do asynchronous processing (not blocking the GUI) without even needing to launch threads. Using threads or processes only helps in two ways:
- you can use a local continuous loop for computation, making state management easier
- the operating system knows how to split processes and threads onto multiple CPU cores
Avoiding the misuse of threads and instead learning to think asynchronously will save you BIG headaches in the future, I promise. This is made even easier (than C) in functional languages and languages that support closures because writing asynchronous callbacks using closures is a snap.
]]>However, the part where they are totally wrong is this: They want to punish society for the actions of a few individuals, and at the same time, refuse to punish a few individuals who are clearly deviating from society. Your example here serves the first part, where every-day law-abiding people are subject to more and more scrutiny by the government, which should be the servant of the people, and not the master.
Examples for the second part are also common, such as any time a murderer or rapist gets off with an easy sentence.
I say let the internet be free and shoot the pedophiles.
]]>I don’t recall anyone getting a chance to vote for Gordon Brown’s government.
]]>The plan was to create a value on which I could call ‘getAttributeValue’, but on which I could also call all the existing Node functions (i.e. ‘attribute’). I can’t see a way to do that without manually wrapping each of the functions:
class NodePlus(value: scala.xml.Node) {
def getAttributeValue(name: String): String = value.attribute(name).get.first.text
def attribute(name: String): Option[NodeSeq] = value.attribute(name)
… etc…
}
The issue with that approach is that it’s brittle to changes in the Node class (which would be an issue if Node was something I’d written myself rather than something in the API).
]]> implicit def nodeToNodePlus(node: scala.xml.Node) = new NodePlus(node)
class NodePlus(value: scala.xml.Node) {
def getAttributeValue(name: String): String = value.attribute(name).get.first.text
}
.getAttributeValue(”id”) // == “world”
]]>