www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Allocators

reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
I recall from discussion a while back that various custom allocators are in the 
works as alternatives to the GC.

Can anyone advise on their status and give a rough idea of what will be offered?

Perhaps this should have gone in D.learn but as it's about language
development, 
the main forum seems like the best place to open discussion.
Aug 23 2013
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 23 August 2013 at 11:27:06 UTC, Joseph Rushton 
Wakeling wrote:
 I recall from discussion a while back that various custom 
 allocators are in the works as alternatives to the GC.

 Can anyone advise on their status and give a rough idea of what 
 will be offered?

 Perhaps this should have gone in D.learn but as it's about 
 language development, the main forum seems like the best place 
 to open discussion.

I see Andrei running away !
Aug 23 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-08-23 13:33, Andrej Mitrovic wrote:

 I see an upcoming drinking game at the next dconf. A shot of whiskey
 anytime anyone mentions allocators. :P

It would be pretty bad if the allocator problem hasn't been solved a year from now, assuming the next dconf will be in about a year. -- /Jacob Carlborg
Aug 23 2013
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/23/2013 07:27 PM, Peter Alexander wrote:

Or shared. Or const. Or scope. Or Object methods. There's quite a few unresolved issues!

Add compile-time reflection.
Aug 23 2013
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/23/2013 10:08 PM, Peter Alexander wrote:
 On Friday, 23 August 2013 at 20:04:28 UTC, H. S. Teoh wrote:
 What's the problem with const again?

I'm thinking mainly of const postblit, and the ramifications of solving that.

What problem does const postblit have that a const constructor does not have?
Aug 23 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/24/2013 12:42 AM, Peter Alexander wrote:
 On Friday, 23 August 2013 at 20:20:21 UTC, Timon Gehr wrote:
 On 08/23/2013 10:08 PM, Peter Alexander wrote:
 On Friday, 23 August 2013 at 20:04:28 UTC, H. S. Teoh wrote:
 What's the problem with const again?

I'm thinking mainly of const postblit, and the ramifications of solving that.

What problem does const postblit have that a const constructor does not have?

Currently, const postblit completely breaks the type system. struct Foo { this(this) { *p = 2; } int* p; } ...

That's a mutable postblit, but I see the point.
 void main()
 {
      import std.stdio;
      immutable int i = 1;
      const(Foo) a = const(Foo)(&i);
      const(Foo) b = a;

I think this line should fail for lack of an appropriately qualified postblit.
      writeln(a.p, " ", *a.p);
      writeln(b.p, " ", *b.p);
      writeln(&i, " ", i);
 }

 For me, this gives:

 7FFF5257D418 2
 7FFF5257D418 2
 7FFF5257D418 1

 The immutable int is changed, and apparently the same address has two
 different values at the same time!

 I'm not aware of any way to do this with constructors, but maybe I'm
 just not aware :-)

import std.stdio; void main(){ void check(immutable(int)* ptr){ writeln(ptr," ",*ptr); } struct S{ immutable(int) x; this(int)const{ check(&x); x=2; check(&x); } } auto s = S(0); } 7FFFAFAA4B80 0 7FFFAFAA4B80 2
Aug 24 2013
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
26-Aug-2013 03:03, Dicebot пишет:
 On Sunday, 25 August 2013 at 22:46:16 UTC, David Nadlinger wrote:
 On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander wrote:
 Or shared

… starting with the fact that we don't have a well-defined memory model at all – on a fundamental level, multithreaded programming in D is guesswork (resp. looking at the compiler implementation) right now!
 […] There's quite a few unresolved issues!

Also add aliasing semantics to the list: http://d.puremagic.com/issues/show_bug.cgi?id=10750 David

It is a wonder it works at all! :D

Well C++ got away with it for 10+ years not even having a notion of a thread. And since globals are defined as thread-local, there is some notion of memory model isn't it? ;) -- Dmitry Olshansky
Aug 26 2013
prev sibling next sibling parent "Andrej Mitrovic" <andrej.mitrovich gmail.com> writes:
On Friday, 23 August 2013 at 11:30:01 UTC, deadalnix wrote:
 I see Andrei running away !

I see an upcoming drinking game at the next dconf. A shot of whiskey anytime anyone mentions allocators. :P
Aug 23 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Friday, 23 August 2013 at 11:33:11 UTC, Andrej Mitrovic wrote:
 On Friday, 23 August 2013 at 11:30:01 UTC, deadalnix wrote:
 I see Andrei running away !

I see an upcoming drinking game at the next dconf. A shot of whiskey anytime anyone mentions allocators. :P

Or auto ref. ;)
Aug 23 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 23 August 2013 at 11:40:48 UTC, Namespace wrote:
 On Friday, 23 August 2013 at 11:33:11 UTC, Andrej Mitrovic 
 wrote:
 On Friday, 23 August 2013 at 11:30:01 UTC, deadalnix wrote:
 I see Andrei running away !

I see an upcoming drinking game at the next dconf. A shot of whiskey anytime anyone mentions allocators. :P

Or auto ref. ;)

Comparing to allocators, "auto ref" is only worth sip of beer. Those are pretty close to "eternal classics" state :)
Aug 23 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Friday, 23 August 2013 at 13:06:22 UTC, Dicebot wrote:
 On Friday, 23 August 2013 at 11:40:48 UTC, Namespace wrote:
 On Friday, 23 August 2013 at 11:33:11 UTC, Andrej Mitrovic 
 wrote:
 On Friday, 23 August 2013 at 11:30:01 UTC, deadalnix wrote:
 I see Andrei running away !

I see an upcoming drinking game at the next dconf. A shot of whiskey anytime anyone mentions allocators. :P

Or auto ref. ;)

Comparing to allocators, "auto ref" is only worth sip of beer. Those are pretty close to "eternal classics" state :)

As long as it is german beer... ;)
Aug 23 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Friday, 23 August 2013 at 11:30:01 UTC, deadalnix wrote:
 I see Andrei running away !

So far, this is the best description of current situation regarding allocators.
Aug 23 2013
prev sibling next sibling parent reply "Brian Rogoff" <brogoff gmail.com> writes:
On Friday, 23 August 2013 at 11:27:06 UTC, Joseph Rushton 
Wakeling wrote:
 I recall from discussion a while back that various custom 
 allocators are in the works as alternatives to the GC.

 Can anyone advise on their status and give a rough idea of what 
 will be offered?

It seems you're far from being the only interested party! Has anyone tried porting an existing allocator library from C++? Looking over the dconf proceedings, HeapLayers was mentioned as an inspiration for a future D allocators library; would a port make sense? I remember seeing a D2 region allocator, but it appeared to be abandonware. Assuming you have a really great allocator library, how would that work with the existing GC requiring features of D? For example, could you have all of your slicing, classes, exceptions, etc. handled by a region allocator? -- Brian
Aug 23 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
23-Aug-2013 18:31, Brian Rogoff пишет:
 On Friday, 23 August 2013 at 11:27:06 UTC, Joseph Rushton Wakeling wrote:
 I recall from discussion a while back that various custom allocators
 are in the works as alternatives to the GC.

 Can anyone advise on their status and give a rough idea of what will
 be offered?

It seems you're far from being the only interested party! Has anyone tried porting an existing allocator library from C++? Looking over the dconf proceedings, HeapLayers was mentioned as an inspiration for a future D allocators library; would a port make sense? I remember seeing a D2 region allocator, but it appeared to be abandonware.

It works. It has no updates for some time, but there isn't anything wrong with it. It just failed to establish the new allocator scheme so it's just a nice piece of 3rd party library.
 Assuming you have a really great allocator library, how would that work
 with the existing GC requiring features of D? For example, could you
 have all of your slicing, classes, exceptions, etc. handled by a region
 allocator?

Hardly (if we are not to forget about safe), but I assume a thread-local GC would solve a lot of problems. -- Dmitry Olshansky
Aug 23 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 23/08/13 13:29, deadalnix wrote:
 I see Andrei running away !

That was what I feared ... :-)
Aug 23 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Friday, 23 August 2013 at 11:40:48 UTC, Namespace wrote:
 On Friday, 23 August 2013 at 11:33:11 UTC, Andrej Mitrovic 
 wrote:
 On Friday, 23 August 2013 at 11:30:01 UTC, deadalnix wrote:
 I see Andrei running away !

I see an upcoming drinking game at the next dconf. A shot of whiskey anytime anyone mentions allocators. :P

Or auto ref. ;)

Or shared. Or const. Or scope. Or Object methods. There's quite a few unresolved issues!
Aug 23 2013
prev sibling next sibling parent "w0rp" <devw0rp gmail.com> writes:
new AllocatorPost;
Aug 23 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander wrote:
 On Friday, 23 August 2013 at 11:40:48 UTC, Namespace wrote:
 On Friday, 23 August 2013 at 11:33:11 UTC, Andrej Mitrovic 
 wrote:
 On Friday, 23 August 2013 at 11:30:01 UTC, deadalnix wrote:
 I see Andrei running away !

I see an upcoming drinking game at the next dconf. A shot of whiskey anytime anyone mentions allocators. :P

Or auto ref. ;)

Or shared. Or const. Or scope. Or Object methods. There's quite a few unresolved issues!

Oh, these I've completely forgotten. The most of these are much older than auto ref. :D
Aug 23 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Aug 23, 2013 at 09:55:05PM +0200, Namespace wrote:
 On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander wrote:
On Friday, 23 August 2013 at 11:40:48 UTC, Namespace wrote:
On Friday, 23 August 2013 at 11:33:11 UTC, Andrej Mitrovic
wrote:
On Friday, 23 August 2013 at 11:30:01 UTC, deadalnix wrote:
I see Andrei running away !

I see an upcoming drinking game at the next dconf. A shot of whiskey anytime anyone mentions allocators. :P

Or auto ref. ;)

Or shared. Or const.


What's the problem with const again?
Or scope.


Yeah this one is pretty high up on my wishlist right now. But it seems like everybody knows what it should do, but nobody knows how to implement it.
Or Object methods.


Wasn't the latest consensus to get rid of them all? Though it does put the implementation at odds with TDPL...
There's quite a few unresolved issues!

Oh, these I've completely forgotten. The most of these are much older than auto ref. :D

There's also the new AA implementation, which hasn't progressed in 2 years. :-( T -- IBM = I'll Buy Microsoft!
Aug 23 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Friday, 23 August 2013 at 20:04:28 UTC, H. S. Teoh wrote:
 What's the problem with const again?

I'm thinking mainly of const postblit, and the ramifications of solving that.
Or Object methods.


Wasn't the latest consensus to get rid of them all? Though it does put the implementation at odds with TDPL...

Yeah, I think so, but doing so is a really big change!
Aug 23 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, August 23, 2013 13:03:02 H. S. Teoh wrote:
 On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander wrote:
Or const.


What's the problem with const again?

Just the issues with it an Object AFAIK. Or Object methods.
 
 Wasn't the latest consensus to get rid of them all? Though it does put
 the implementation at odds with TDPL...

That's what we agreed on. The problem is implementing the changes. I have a pull for druntime which starts the process for opEquals, but compiler changes are likely to be required to get all of this to work, and we may need the AA implementation to be fixed first as well. So, there are some serious roadblocks. The most recent discussion on it was http://forum.dlang.org/thread/mailman.214.1369617617.13711.digitalmars-d puremagic.com though it looks like Kenji's reply in that thread was split off: http://forum.dlang.org/thread/7851915.gvRHKl6iG7 lyonel An enterprising compiler dev could probably get us most of the way there pretty quickly though based on some of the ideas in that discussion. I don't know if we can avoid needing to fix the AAs first or not though, and you know better than most of us how much of a mess that is. - Jonathan M Davis
Aug 23 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, August 23, 2013 22:08:40 Peter Alexander wrote:
 On Friday, 23 August 2013 at 20:04:28 UTC, H. S. Teoh wrote:
 What's the problem with const again?

I'm thinking mainly of const postblit, and the ramifications of solving that.

Ooh. I keep forgetting about that. That's a big one and is arguably postblit's biggest flaw. - Jonathan M Davis
Aug 23 2013
prev sibling next sibling parent "Kapps" <opantm2+spam gmail.com> writes:
On Friday, 23 August 2013 at 20:18:53 UTC, Timon Gehr wrote:
 On 08/23/2013 07:27 PM, Peter Alexander wrote:

Or shared. Or const. Or scope. Or Object methods. There's quite a few unresolved issues!

Add compile-time reflection.

The current compile-time reflection seems to be capable of doing most things to at least generate runtime reflection. What do you find missing with it? Or is it just the way it's presented?
Aug 23 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Aug 23, 2013 at 10:18:53PM +0200, Timon Gehr wrote:
 On 08/23/2013 07:27 PM, Peter Alexander wrote:

Or shared. Or const. Or scope. Or Object methods. There's quite a few unresolved issues!

Add compile-time reflection.

I thought __traits solved that problem? In an ugly way, perhaps, but is there something that can't be solved with __traits? T -- Two wrongs don't make a right; but three rights do make a left...
Aug 23 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Friday, 23 August 2013 at 20:20:21 UTC, Timon Gehr wrote:
 On 08/23/2013 10:08 PM, Peter Alexander wrote:
 On Friday, 23 August 2013 at 20:04:28 UTC, H. S. Teoh wrote:
 What's the problem with const again?

I'm thinking mainly of const postblit, and the ramifications of solving that.

What problem does const postblit have that a const constructor does not have?

Currently, const postblit completely breaks the type system. struct Foo { this(this) { *p = 2; } int* p; } void main() { import std.stdio; immutable int i = 1; const(Foo) a = const(Foo)(&i); const(Foo) b = a; writeln(a.p, " ", *a.p); writeln(b.p, " ", *b.p); writeln(&i, " ", i); } For me, this gives: 7FFF5257D418 2 7FFF5257D418 2 7FFF5257D418 1 The immutable int is changed, and apparently the same address has two different values at the same time! I'm not aware of any way to do this with constructors, but maybe I'm just not aware :-)
Aug 23 2013
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Friday, 23 August 2013 at 20:42:20 UTC, H. S. Teoh wrote:
 On Fri, Aug 23, 2013 at 10:18:53PM +0200, Timon Gehr wrote:
 On 08/23/2013 07:27 PM, Peter Alexander wrote:
 […]
There's quite a few unresolved issues!

Add compile-time reflection.

I thought __traits solved that problem? In an ugly way, perhaps, but is there something that can't be solved with __traits?

The problem is that the language does not define how to deal with "forward references". At all. There are lots of cases where this matters in practice, for example when using the information obtained by __traits(allMembers, T) to add a new member to T (e.g. in a serialization library). But the canonical example probably is simply: ––– static if (!is(typeof(b))) enum a = 0; static if (!is(typeof(a))) enum b = 0; // What is defined? a? b? both? Or is this illegal code? ––– Right now, DMD is rather liberal in what it accepts, but what exactly is legal is not clear, and evaluation order is completely unspecified. This is a huge problem, as you end up writing a piece of code and seeing that it compiles fine and behaves as you would intuitively expect, assume that it is legal, only to have the compiler choke on it or behave differently when the next release comes out. David
Aug 23 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, August 23, 2013 22:20:21 Timon Gehr wrote:
 On 08/23/2013 10:08 PM, Peter Alexander wrote:
 On Friday, 23 August 2013 at 20:04:28 UTC, H. S. Teoh wrote:
 What's the problem with const again?

I'm thinking mainly of const postblit, and the ramifications of solving that.

What problem does const postblit have that a const constructor does not have?

A copy constructor creates a new object from scratch, so it doesn't modify anything, and creating it as const is fine. postblit on the other hand does a memcopy of the object first and then modifies select portions of the copy. When constructing a const or immutable object, that would mean that you have to modify a const or immutable object in order to mutate the portions that the postblit is supposed to be mutating. We need a way to construct a copy rather than copy and mutate, so AFAIK, we basically need to add copy constructors to solve this problem. - Jonathan M Davis
Aug 23 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 8/24/13, Peter Alexander <peter.alexander.au gmail.com> wrote:
 The immutable int is changed

Yeah.
 and apparently the same address has
 two different values at the same time!

Apparently, but it's not what happens. The compiler optimizes the call to writeln by substituting 'i' with its value. This would be a safe optimization based on immutability rules, were it not for the postblit bug.
Aug 23 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander wrote:
 On Friday, 23 August 2013 at 11:40:48 UTC, Namespace wrote:
 On Friday, 23 August 2013 at 11:33:11 UTC, Andrej Mitrovic 
 wrote:
 On Friday, 23 August 2013 at 11:30:01 UTC, deadalnix wrote:
 I see Andrei running away !

I see an upcoming drinking game at the next dconf. A shot of whiskey anytime anyone mentions allocators. :P

Or auto ref. ;)

Or shared. Or const. Or scope. Or Object methods. There's quite a few unresolved issues!

Or: http://forum.dlang.org/thread/mailman.835.1332024849.4860.digitalmars-d puremagic.com#post-wyloejdfqjzglqbybpxv:40forum.dlang.org
Aug 24 2013
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Saturday, 24 August 2013 at 19:15:13 UTC, Namespace wrote:
 On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander 
 wrote:
 There's quite a few unresolved issues!

Or: http://forum.dlang.org/thread/mailman.835.1332024849.4860.digitalmars-d puremagic.com#post-wyloejdfqjzglqbybpxv:40forum.dlang.org

That's not a language issue, that's a compiler feature request that does not affect the language semantics at all. David
Aug 24 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Saturday, 24 August 2013 at 20:56:09 UTC, David Nadlinger 
wrote:
 On Saturday, 24 August 2013 at 19:15:13 UTC, Namespace wrote:
 On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander 
 wrote:
 There's quite a few unresolved issues!

Or: http://forum.dlang.org/thread/mailman.835.1332024849.4860.digitalmars-d puremagic.com#post-wyloejdfqjzglqbybpxv:40forum.dlang.org

That's not a language issue, that's a compiler feature request that does not affect the language semantics at all. David

What's about the probable change of virtual by default -> final by default?
Aug 24 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 8/24/13, Namespace <rswhite4 googlemail.com> wrote:
 What about the probable change of virtual by default -> final
 by default?

Btw, can someone find the link to the forum thread where the last discussion of this took place? I remember Walter agreeing to something, but can't recall anymore.
Aug 24 2013
prev sibling next sibling parent "Kapps" <opantm2+spam gmail.com> writes:
On Saturday, 24 August 2013 at 21:53:47 UTC, Andrej Mitrovic 
wrote:
 On 8/24/13, Namespace <rswhite4 googlemail.com> wrote:
 What about the probable change of virtual by default -> final
 by default?

Btw, can someone find the link to the forum thread where the last discussion of this took place? I remember Walter agreeing to something, but can't recall anymore.

It seemed like eventually Walter supported virtual by default, but nothing came of it. For some reason I can't find the thread anymore with Google.
Aug 24 2013
prev sibling next sibling parent "luminousone" <rd.hunt gmail.com> writes:
On Saturday, 24 August 2013 at 22:41:54 UTC, Kapps wrote:
 On Saturday, 24 August 2013 at 21:53:47 UTC, Andrej Mitrovic 
 wrote:
 On 8/24/13, Namespace <rswhite4 googlemail.com> wrote:
 What about the probable change of virtual by default -> final
 by default?

Btw, can someone find the link to the forum thread where the last discussion of this took place? I remember Walter agreeing to something, but can't recall anymore.

It seemed like eventually Walter supported virtual by default, but nothing came of it. For some reason I can't find the thread anymore with Google.

Pretty sure Walter supported final by default, he even laid out a transition plan as I recall. Seems like Manu was involved, so asking him might bear fruit on that question.
Aug 24 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Saturday, 24 August 2013 at 21:53:47 UTC, Andrej Mitrovic 
wrote:
 On 8/24/13, Namespace <rswhite4 googlemail.com> wrote:
 What about the probable change of virtual by default -> final
 by default?

Btw, can someone find the link to the forum thread where the last discussion of this took place? I remember Walter agreeing to something, but can't recall anymore.

http://forum.dlang.org/thread/yzsqwejxqlnzryhrkfuq forum.dlang.org?page=28#post-koqkhc:244nn:241:40digitalmars.com
Aug 25 2013
prev sibling next sibling parent "Mr. Anonymous" <mailnew4ster gmail.com> writes:
On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander wrote:
 On Friday, 23 August 2013 at 11:40:48 UTC, Namespace wrote:
 On Friday, 23 August 2013 at 11:33:11 UTC, Andrej Mitrovic 
 wrote:
 On Friday, 23 August 2013 at 11:30:01 UTC, deadalnix wrote:
 I see Andrei running away !

I see an upcoming drinking game at the next dconf. A shot of whiskey anytime anyone mentions allocators. :P

Or auto ref. ;)

Or shared. Or const. Or scope. Or Object methods. There's quite a few unresolved issues!

How about adding those to the TODO list? e.g. http://dlang.org/todo.html Or make a wiki page?
Aug 25 2013
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander wrote:
 Or shared

… starting with the fact that we don't have a well-defined memory model at all – on a fundamental level, multithreaded programming in D is guesswork (resp. looking at the compiler implementation) right now!
 […] There's quite a few unresolved issues!

Also add aliasing semantics to the list: http://d.puremagic.com/issues/show_bug.cgi?id=10750 David
Aug 25 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 8/25/13, Namespace <rswhite4 googlemail.com> wrote:
 http://forum.dlang.org/thread/yzsqwejxqlnzryhrkfuq forum.dlang.org?page=28#post-koqkhc:244nn:241:40digitalmars.com

Thanks!
Aug 25 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Sunday, 25 August 2013 at 22:46:16 UTC, David Nadlinger wrote:
 On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander 
 wrote:
 Or shared

… starting with the fact that we don't have a well-defined memory model at all – on a fundamental level, multithreaded programming in D is guesswork (resp. looking at the compiler implementation) right now!
 […] There's quite a few unresolved issues!

Also add aliasing semantics to the list: http://d.puremagic.com/issues/show_bug.cgi?id=10750 David

It is a wonder it works at all! :D
Aug 25 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Monday, 26 August 2013 at 07:55:56 UTC, Dmitry Olshansky wrote:
 It is a wonder it works at all! :D

Well C++ got away with it for 10+ years not even having a notion of a thread. And since globals are defined as thread-local, there is some notion of memory model isn't it? ;)

What I was (half-)joking about here is that D has _lot_ of crucial design problems, listing them all at once can inspire truly apocalyptic feelings. And still in practice it works and works pretty damn good. Can a mortal mind even imagine how awesome can it be if all those issues are addressed and fixed? :)
Aug 26 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 26 August 2013 at 14:06:42 UTC, Dicebot wrote:
 On Monday, 26 August 2013 at 07:55:56 UTC, Dmitry Olshansky 
 wrote:
 It is a wonder it works at all! :D

Well C++ got away with it for 10+ years not even having a notion of a thread. And since globals are defined as thread-local, there is some notion of memory model isn't it? ;)

What I was (half-)joking about here is that D has _lot_ of crucial design problems, listing them all at once can inspire truly apocalyptic feelings. And still in practice it works and works pretty damn good. Can a mortal mind even imagine how awesome can it be if all those issues are addressed and fixed? :)

Well, first it would break a lot of code; And second, we'd probably discover a whole new class of problem. But yeah, that'd be great :P
Aug 26 2013