On Tue, 22 Apr 2014 09:48:28 -0400, Ola Fosheim Grøstad
<[email protected]> wrote:
On Tuesday, 22 April 2014 at 13:39:54 UTC, Steven Schveighoffer wrote:
On Tue, 22 Apr 2014 09:29:28 -0400, Ola Fosheim Grøstad Can you explain
this?
When you use a C/C++ framework you don't know what happens to the
pointers you hand to it.
Those are typically well-documented, but yes, you rely on "insider"
knowledge. You can mark C functions with the appropriate attributes so the
D compiler can enforce this for you. I think we should make reference
counting work, as long as you don't call mischievous library code. We take
a similar approach to other safety aspects of D.
You also don't know which threads call your D-functons from that
framework. (Assuming the framework is multi-threaded). To know this you
are required to know the internals of the framework you are utilizing or
inject runtime guards into your D functions?
Or just mark those objects sent into the framework as shared. Having
multi-threaded RC isn't bad, just not as efficient.
One thing that would be nice is to allow moving a data pointer from one
thread to another. In other words, as long as your data is contained, it
can pass from one thread to another, and still be considered unshared.
I think sooner or later, we are going to have to figure that one out.
By mistake? How?
By insertion into a global datastructure that happens at a lower layer
than the higher level you allocate on.
I think this is what you are talking about above, or is there something
else?
-Steve
