<!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:FBBCF01E-7978-4FD1-AC4D-C117DF523842@michelf.com"
type="cite">
<pre wrap="">Le 2010-01-10 à 22:47, Graham St Jack a écrit :
</pre>
<blockquote type="cite">
<pre wrap="">I'm happy with things being carefully wrapped and auto-magic. However, surely the message channel (or whatever it is called) object itself will have be shared (and its externally accessible methods synchronized), otherwise we are cheating. We have a object whose sole purpose in life is to be shared by multiple threads, so surely if anything is shared, this one has to be.
If this is the case, then we need a mechanism to stop "shared" from leaking out into the whole code base.
</pre>
</blockquote>
<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>
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. <br>
<br>
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.<br>
<br>
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.<br>
</body>
</html>