On Thu, 16 Feb 2017 21:49 +0000 Tim Streater <t...@clothears.org.uk> wrote:
> > What's inherently wrong with threads in principle is that there is > > no logic that describes them, and consequently no compiler to > > control that logic. > > [snip remainder of long whinge about threads] > > Sounds, then, like I'd better eliminate threads from my app. In which > case when the user initiates some action that may take some minutes > to complete, he can just lump it when the GUI becomes unresponsive. [snip chest thumping] You didn't refute my assertion, and facts refute yours. There has been a GUI in use for some 30 years, dating back to your VMS days, that is single-threaded. I'm sure you've heard of it, the X Window System? If your particular GUI system is based on threads, like, say, Microsoft Windows, then, yes, you're pretty much cornered into using threads. But that doesn't change the fact that you have no compiler support to verify the correctness of memory access over the time domain. It doesn't change the fact that the OS has subverted the guarantees your language would otherwise provide, such as the atomicity of ++i noted elsewhere in this thread. WR Stevens describes 4 models for managing concurrency: 1. Mutilplexing: select(2) 2. Multiprocessing 3. Asynchronous callbacks 4. Signal-driven None of those subvert the semantics of the programming language. In each case, at any one moment there is only one thread of control over any given section of logic. Hoare had already published "Communicating Sequential Processes" (http://www.usingcsp.com/cspbook.pdf) when it hired David Cutler to design Windows NT. It's too bad they adopted threads as their concurrency-management medium. If they'd chosen CSP instead, maybe they wouldn't have set computing back two decades. --jkl _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
