On 18-11-2012 05:58, Jonathan M Davis wrote:
On Sunday, November 18, 2012 05:51:00 Alex Rønne Petersen wrote:
On 18-11-2012 05:46, Jonathan M Davis wrote:
I don't know if we can answer this for sure at the moment given the
ongoing
discussion on shared, but looking at core.sync, it occurred to me that
there's a major problem with the classes in there. None of the work with
shared. And unless I'm missing something here, I don't see how many of
them are even useful as anything other than shared. After all, what good
is a mutex which is thread-local? But none of the methods on Mutex or its
friends are shared.
So, the question is should the all have their methods shared? And if they
should, is there any reason to have non-shared overloads for them? What
good are they as anything other than shared? How is anyone using them
right now?
- Jonathan M Davis
Not at this point in time. It would break a ridiculous amount of code if
we did this, given the current extremely annoying nature of shared.
Most D code I have seen in the wild just shares mutexes, conditions, etc
with __gshared or some other mechanism anyway, so I don't think there's
anything to gain. Like, what would shared actually buy you here?
__gshared is a good reason for leaving non-shared overloads, but isn't code
really supposed to be using shared and not __gshared unless it's specifically
extern(C)? That being the case, I'd expect shared to be the correct thing to
use with mutexes normally, and right now, that won't work without a ton of
casting or adding shared overloads.
- Jonathan M Davis
I don't know what anything that has to do with shared is supposed or not
supposed to do. It is not clear, even to the primary language designers,
what shared actually is, so I really can't say anything to this...
All I can say is, let's wait with this until we know what shared is
going to actually do. We don't want to do something we'll regret later.
--
Alex Rønne Petersen
[email protected]
http://lycus.org
