<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Michel Fortin wrote:
<blockquote cite="mid:60B9C88A-60F0-405B-B67E-9EEEAC918D9E@michelf.com"
type="cite">
<pre wrap="">Le 2010-01-11 à 18:10, Graham St Jack a écrit :
</pre>
<blockquote type="cite">
<pre wrap="">Michel Fortin wrote:
</pre>
<blockquote type="cite">
<pre wrap="">When your browser requests a web page to a server, it sends messages and receives back replies. But it doesn't need the browser need to have a "shared" object with the server. Instead, you have a socket on each side and both get connected through the operating system's TCP/IP stack auto-magic.
In the same way, a message-passing API, especially one that intends to go beyond threads, doesn't need and shouldn't expose any shared object. That doesn't mean the implementation won't use shared for thread-to-thread communications, but the user of the API shouldn't need to see that.
</pre>
</blockquote>
<pre wrap="">I understand what you are saying, but your example is for inter-process communications, and the shared objects you talk about are external to the process, in non-D code.
</pre>
</blockquote>
<pre wrap=""><!---->
It doesn't change a thing. Passing objects by reference should be an optimization, not a requirement. It'd be pretty dumb if it wasn't possible between thread, I agree. But we don't need to make the user aware of it.
</pre>
</blockquote>
I think we are talking at cross-purposes. The shared objects I am
talking about aren't the messages - they are the communication channels
that the messages pass through.<br>
<blockquote cite="mid:60B9C88A-60F0-405B-B67E-9EEEAC918D9E@michelf.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">I also understand that the messaging library is attempting to make inter-thread, inter-process and inter-node communications all look the same. I'm not sure this is a good idea, and I for one would like to have a version of the messaging API that used blatantly shared objects for good old-fashioned inter thread message passing. If such a thing doesn't eventuate, I for one would like to be able to build one without having to resort to back-door tricks.
</pre>
</blockquote>
<pre wrap=""><!---->
You will be capable of making your own communication mechanisms using shared. If you can't, it'd mean that shared is pretty dysfunctional.
</pre>
</blockquote>
Happy to hear you say so - that is what I am trying to get
clarification on. Now all I need is some evidence that it is indeed so.<br>
<blockquote cite="mid:60B9C88A-60F0-405B-B67E-9EEEAC918D9E@michelf.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">With communication between threads within a process, we are looking at using the shared keyword to primarily indicate which objects are potentially shared. I still think it is a cop-out to say "this shared object is safe to use, so lets pretend it isn't shared". Sure, that avoids the problems associated with the viral nature of the shared keyword, but does nothing to help us understand how to get the design of shared right.
</pre>
</blockquote>
<pre wrap=""><!---->
If you're talking about immutable, it was Walter's decision to keep the type system simpler by having immutable and shared-immutable be the same. And I don't think reopening that debate will lead to anything.
</pre>
</blockquote>
I'm perfectly happy with immutable messages being implicitly shared. It
is the communication channels that I am interested in here.<br>
<blockquote cite="mid:60B9C88A-60F0-405B-B67E-9EEEAC918D9E@michelf.com"
type="cite">
<pre wrap="">
If you're talking about the message passing API... well I'm not the one designing it but if I were the internal implementation for thread-to-thread communication would use shared, but the user-visible parts (the API) wouldn't. For instance, you could have this struct:
struct MessageDispatcher {
private shared MessageQueue messageQueue;
void send(string[] message) {
synchronized (messageQueue) {
messageQueue.add(message);
}
}
string receive() {
synchronized (messageQueue) {
while (messageQueue.empty)
messageQueue.wait();
return messageQueue.get();
}
}
}
And you would use the endpoint like this:
void main() {
MessageDispatcher dispatcher = createOneSomehow();
span(&threadFunc, endpoint); // endpoint passed *by copy*
endpoint.send("hello");
}
void threadFunc(MessageDispatcher dispatcher) {
string message = dispatcher.receive(); // blocking
// ... use message
}
I'm not sure how putting "shared" in the user's code would help anything here. Sure, if I wasn't passing an immutable string it wouldn't work, but that's just a crude example. I'd expect the message passing API to accept anything as a message. If the message is neither immutable nor shared, then the message passing API should make a copy; if it is immutable or shared, then it can and should be passed as-is to the other thread. Does that make sense?
</pre>
</blockquote>
I get it. The only thing I have an issue with is my belief that the
MessageDispatcher should be a shared struct so that the compiler can do
its thing, and I can keep track of where my inter-thread communication
is happening more easily.<br>
<br>
By the way, what you have described is essentially the same as my own
message passing mechanisms, right down to having a synchronized block
inside the methods instead of synchronizing the methods, preventing the
compiler from tagging the methods as shared.<br>
<br>
</body>
</html>