Jeremie Pelletier wrote: > I myself couldn't live without threads or references, but I agree that > mixing the two can lead to interesting scenarios to debug. Just try and > code a responsive GUI without using threads, the application will "hang" > everytime you're not going back to the main loop every few milliseconds. > Or doing network I/O without bringing your program to a crawl, of course > you could use async I/O but where is that I/O gonna run without a > background thread to support it :)
<rant> See, people equate "parallel execution" with "threads" these days which is half the problem. Threads are a TERRIBLE abstraction, because they don't. There's no protection. Almost every time I express the opinion that threads are broken, people automatically assume I think we should all go back to single-core machines and cooperative multitasking. It's like if I said I don't like Coke that I'm somehow against all beverages. A while ago, I was playing with a toy language design which used value semantics for everything. The one exception was references, but they had two big differences from how, for example, D implements them: 1. They could only point to the heap, and could not point to any pre-existing value. If you, for example, took a ref to an array, it would actually copy the array to the heap. 2. Refs to mutable values could only be dereferenced by their "owning" thread; other threads couldn't even look at the contents. A thread could transfer ownership of a ref to another thread, or disown it entirely at which point it became globally immutable. Because of this, threads in the language couldn't even see each other's mutable data (there were no process-globals, only thread-global); they had to communicate via message passing. In something like that, you don't need to worry about threads interacting badly, because they can't interact except at specific points in the program. For something like a GUI, you'd have the GUI in one thread and do the processing in another. Instead of having to worry about locking and synchronising, you just send the other thread a "do this" message. Of course, something like that would never get into D. Oh well. :) Where was I? </rant> > Besides, the upcoming shared qualifier is there to address those issues. > > You might want to look at this article, I came across it a few months > ago and found it rather insightful, it just could change your view on > references: > http://blogs.msdn.com/ericlippert/archive/2009/02/17/references-are-not-addresses.aspx I've read it before. It doesn't apply because we're talking about D, not C#. Conceptually, it's correct, but D is a systems programming language. If you're going to deal with things like the definition of purity, then you HAVE to know what a reference really is and how it works. If you just use pure, you don't care. It's like how if you're working on the CLR itself, you'd need to know how references are implemented. If you're USING the CLR, it's immaterial in most cases. In C#, if you talk about "Beethoven", then it's always the same Beethoven. The only way the definition of Beethoven would change is if everyone in the universe forgot who he was first. But in D, that's not entirely true. You can hit the GC over the head with a "delete" and it'll forget. Sometimes it'll forget because you accidentally stored the only remaining reference in a malloc'ed struct RIGHT when some other thread triggered a collect and oh dear. I would like to clarify, however, that I think it is fairly reasonable to expect this optimisation to work. It's just that I've been bitten by threading issues so very many times that I work on the basis that given half a chance, threading will completely screw your program. That said, I think I'm getting too ranty, so I'll just leave it at that.
