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.
