On Mon, Oct 22, 2018 at 6:00 AM Timon Gehr via Digitalmars-d
wrote:
>
> On 22.10.18 12:26, Timon Gehr wrote:
> > ---
> > module borked;
> >
> > void atomicIncrement(int* p)@system{
> > import core.atomic;
> > atomicOp!("+=",int,int)(*cast(shared(int)*)p,1);
> > }
> >
> > struct
On Mon, Oct 22, 2018 at 4:50 AM Stanislav Blinov via Digitalmars-d
wrote:
>
> On Monday, 22 October 2018 at 00:22:19 UTC, Manu wrote:
>
> > No no, they're repeated, not scattered, because I seem to have
> > to keep repeating it over and over, because nobody is reading
> > the text, or perhaps
On Mon, Oct 22, 2018 at 3:30 AM Timon Gehr via Digitalmars-d
wrote:
>
> On 22.10.18 02:54, Manu wrote:
> > On Sun, Oct 21, 2018 at 5:40 PM Timon Gehr via Digitalmars-d
> > wrote:
> >>
> >> On 21.10.18 21:04, Manu wrote:
> >>> On Sun, Oct 21, 2018 at 12:00 PM Timon Gehr via Digitalmars-d
> >>>
On Monday, 22 October 2018 at 14:31:28 UTC, Timon Gehr wrote:
On 22.10.18 16:09, Simen Kjærås wrote:
On Monday, 22 October 2018 at 13:40:39 UTC, Timon Gehr wrote:
module reborked;
import atomic;
void main()@safe{
auto a=new Atomic!int;
import std.concurrency;
On Monday, 22 October 2018 at 00:22:19 UTC, Manu wrote:
On Sun, Oct 21, 2018 at 2:35 PM Walter Bright via Digitalmars-d
wrote:
On 10/21/2018 2:08 PM, Walter Bright wrote:
> On 10/21/2018 12:20 PM, Nicholas Wilson wrote:
>> Yes, but the problem you describe is arises from implicit
>>
On 22.10.18 16:09, Simen Kjærås wrote:
On Monday, 22 October 2018 at 13:40:39 UTC, Timon Gehr wrote:
module reborked;
import atomic;
void main()@safe{
auto a=new Atomic!int;
import std.concurrency;
spawn((shared(Atomic!int)* a){ ++*a; }, a);
++a.tupleof[0];
}
Finally! Proof
On Monday, 22 October 2018 at 00:22:19 UTC, Manu wrote:
On Sun, Oct 21, 2018 at 2:35 PM Walter Bright via Digitalmars-d
wrote:
Then I don't know what the proposal is. Pieces of it appear to
be scattered over numerous posts, mixed in with other text,
No no, they're repeated, not scattered,
On Monday, 22 October 2018 at 13:40:39 UTC, Timon Gehr wrote:
module reborked;
import atomic;
void main()@safe{
auto a=new Atomic!int;
import std.concurrency;
spawn((shared(Atomic!int)* a){ ++*a; }, a);
++a.tupleof[0];
}
Finally! Proof that MP is impossible. On the other hand,
On 22.10.18 15:26, Simen Kjærås wrote:
Here's the correct version:
module atomic;
void atomicIncrement(int* p) @system {
import core.atomic;
atomicOp!("+=",int,int)(*cast(shared(int)*)p,1);
}
struct Atomic(T) {
// Should probably mark this shared for extra safety,
// but
On 22.10.18 03:01, Manu wrote:
On Sun, Oct 21, 2018 at 5:55 PM Timon Gehr via Digitalmars-d
wrote:
On 22.10.18 02:45, Manu wrote:
On Sun, Oct 21, 2018 at 5:35 PM Timon Gehr via Digitalmars-d
wrote:
On 21.10.18 20:46, Manu wrote:
Shared data is only useful if, at some point, it is
On Monday, 22 October 2018 at 10:26:14 UTC, Timon Gehr wrote:
module borked;
void atomicIncrement(int* p)@system{
import core.atomic;
atomicOp!("+=",int,int)(*cast(shared(int)*)p,1);
}
struct Atomic(T){
private T val;
void opUnary(string op : "++")() shared @trusted {
On 22.10.18 14:39, Aliak wrote:
On Monday, 22 October 2018 at 10:26:14 UTC, Timon Gehr wrote:
---
module borked;
void atomicIncrement(int* p)@system{
import core.atomic;
atomicOp!("+=",int,int)(*cast(shared(int)*)p,1);
}
struct Atomic(T){
private T val;
void opUnary(string op
On 22.10.18 12:26, Timon Gehr wrote:
---
module borked;
void atomicIncrement(int* p)@system{
import core.atomic;
atomicOp!("+=",int,int)(*cast(shared(int)*)p,1);
}
struct Atomic(T){
private T val;
void opUnary(string op : "++")() shared @trusted {
On Monday, 22 October 2018 at 10:26:14 UTC, Timon Gehr wrote:
---
module borked;
void atomicIncrement(int* p)@system{
import core.atomic;
atomicOp!("+=",int,int)(*cast(shared(int)*)p,1);
}
struct Atomic(T){
private T val;
void opUnary(string op : "++")() shared @trusted {
On Monday, 22 October 2018 at 00:22:19 UTC, Manu wrote:
No no, they're repeated, not scattered, because I seem to have
to keep repeating it over and over, because nobody is reading
the text, or perhaps imaging there is a lot more text than
there is.
...
You mean like every post in opposition
On 22.10.18 02:54, Manu wrote:
On Sun, Oct 21, 2018 at 5:40 PM Timon Gehr via Digitalmars-d
wrote:
On 21.10.18 21:04, Manu wrote:
On Sun, Oct 21, 2018 at 12:00 PM Timon Gehr via Digitalmars-d
wrote:
On 21.10.18 17:54, Nicholas Wilson wrote:
As soon as that is done, you've got a data
On Mon, Oct 22, 2018 at 2:30 AM Walter Bright via Digitalmars-d
wrote:
>
> On 10/22/2018 1:34 AM, Manu wrote:
> > I posted it, twice... 2 messages, back to back, and you're responding
> > to this one, and not that one. I'll post it again...
>
>
> Posting it over and over is illustrative of the
On 22/10/2018 10:28 PM, Walter Bright wrote:
On 10/22/2018 1:34 AM, Manu wrote:
I posted it, twice... 2 messages, back to back, and you're responding
to this one, and not that one. I'll post it again...
Posting it over and over is illustrative of the failure of posting
proposal documents to
On 10/22/2018 1:34 AM, Manu wrote:
I posted it, twice... 2 messages, back to back, and you're responding
to this one, and not that one. I'll post it again...
Posting it over and over is illustrative of the failure of posting proposal
documents to the n.g. instead of posting it as a DIP which
On 10/22/2018 1:42 AM, Manu wrote:
You removed whatever comment you're referring to.
If your newsreader cannot find the antecedent, you badly need to use a better
one. Thunderbird handles this rather well, there's no reason to use an inferior one.
Or just click the <- button:
On Mon, Oct 22, 2018 at 12:55 AM Walter Bright via Digitalmars-d
wrote:
>
> On 10/21/2018 11:58 AM, Timon Gehr wrote:
> > [...]
>
> Thank you, Timon, for a nice explanation of what I was trying to express.
You removed whatever comment you're referring to.
I don't understand any of Timon's posts
Third time's the charm maybe?
- repeated, 3rd time
On Sun., 21 Oct. 2018, 2:55 am Walter Bright via Digitalmars-d,
wrote:
>
> On 10/20/2018 11:24 AM, Manu wrote:
> > This is an unfair dismissal.
>
> It has nothing at all to do with fairness. It
On Mon, Oct 22, 2018 at 12:50 AM Walter Bright via Digitalmars-d
wrote:
>
> On 10/21/2018 5:54 PM, Manu wrote:
> > Would you please respond to my messages, and specifically, respond to
> > the code that I presented to you in response to your broken example.
> > Or any of my earlier fragments
On 10/21/2018 11:58 AM, Timon Gehr wrote:
[...]
Thank you, Timon, for a nice explanation of what I was trying to express.
On 10/21/2018 5:54 PM, Manu wrote:
Would you please respond to my messages, and specifically, respond to
the code that I presented to you in response to your broken example.
Or any of my earlier fragments throughout this thread. I've shared
quite a few, and so far, nobody has ever produced a
On Monday, 22 October 2018 at 00:22:19 UTC, Manu wrote:
On Sun, Oct 21, 2018 at 2:35 PM Walter Bright via Digitalmars-d
wrote:
On 10/21/2018 2:08 PM, Walter Bright wrote:
> On 10/21/2018 12:20 PM, Nicholas Wilson wrote:
>> Yes, but the problem you describe is arises from implicit
>>
On Sun, 21 Oct 2018 17:35:38 -0700, Manu wrote:
> On Sun, Oct 21, 2018 at 3:15 PM Neia Neutuladh via Digitalmars-d
> wrote:
>> If we only used your proposal and only used @safe code, we wouldn't
>> have any data races, but that's only because we wouldn't have any
>> shared data. We'd have shared
On Monday, 22 October 2018 at 00:55:00 UTC, Timon Gehr wrote:
On 22.10.18 02:46, Nicholas Wilson wrote:
On Monday, 22 October 2018 at 00:38:33 UTC, Timon Gehr wrote:
I just did,
Link please?
https://forum.dlang.org/post/pqii8k$11u3$1...@digitalmars.com
That contains no code.
Not all of
On Sun, Oct 21, 2018 at 5:55 PM Timon Gehr via Digitalmars-d
wrote:
>
> On 22.10.18 02:45, Manu wrote:
> > On Sun, Oct 21, 2018 at 5:35 PM Timon Gehr via Digitalmars-d
> > wrote:
> >>
> >> On 21.10.18 20:46, Manu wrote:
> Shared data is only useful if, at some point, it is read/written,
>
On Sun, Oct 21, 2018 at 5:40 PM Timon Gehr via Digitalmars-d
wrote:
>
> On 21.10.18 21:04, Manu wrote:
> > On Sun, Oct 21, 2018 at 12:00 PM Timon Gehr via Digitalmars-d
> > wrote:
> >>
> >> On 21.10.18 17:54, Nicholas Wilson wrote:
> >>>
> As soon as that is done, you've got a data race
On Monday, 22 October 2018 at 00:46:04 UTC, Walter Bright wrote:
That's what I was referring to, and Manu's example. It doesn't
work, as I pointed out.
I'm pretty sure it does, but please repeat it.
We will eventually. This started as a "please point out any
problems with this" and has
On Sun, Oct 21, 2018 at 5:50 PM Walter Bright via Digitalmars-d
wrote:
>
> On 10/21/2018 4:12 PM, Nicholas Wilson wrote:
> > On Sunday, 21 October 2018 at 21:32:14 UTC, Walter Bright wrote:
> >> On 10/21/2018 2:08 PM, Walter Bright wrote:
> >>> On 10/21/2018 12:20 PM, Nicholas Wilson wrote:
>
On 22.10.18 02:46, Nicholas Wilson wrote:
On Monday, 22 October 2018 at 00:38:33 UTC, Timon Gehr wrote:
I just did,
Link please?
https://forum.dlang.org/post/pqii8k$11u3$1...@digitalmars.com
On 22.10.18 02:45, Manu wrote:
On Sun, Oct 21, 2018 at 5:35 PM Timon Gehr via Digitalmars-d
wrote:
On 21.10.18 20:46, Manu wrote:
Shared data is only useful if, at some point, it is read/written, presumably by
casting it to unshared in @trusted code. As soon as that is done, you've got a
On 10/21/2018 4:12 PM, Nicholas Wilson wrote:
On Sunday, 21 October 2018 at 21:32:14 UTC, Walter Bright wrote:
On 10/21/2018 2:08 PM, Walter Bright wrote:
On 10/21/2018 12:20 PM, Nicholas Wilson wrote:
Yes, but the problem you describe is arises from implicit conversion in the
other
On Monday, 22 October 2018 at 00:38:33 UTC, Timon Gehr wrote:
I just did,
Link please?
On Sun, Oct 21, 2018 at 5:35 PM Timon Gehr via Digitalmars-d
wrote:
>
> On 21.10.18 20:46, Manu wrote:
> >> Shared data is only useful if, at some point, it is read/written,
> >> presumably by
> >> casting it to unshared in @trusted code. As soon as that is done, you've
> >> got a
> >> data
On Monday, 22 October 2018 at 00:32:35 UTC, Timon Gehr wrote:
This only works if untrusted programmers (i.e. programmers who
are only allowed to write/modify @safe code) are not allowed to
change your class. I.e. it does not work.
This is the basis of the current @safe/@trusted/@system model.
On 21.10.18 21:04, Manu wrote:
On Sun, Oct 21, 2018 at 12:00 PM Timon Gehr via Digitalmars-d
wrote:
On 21.10.18 17:54, Nicholas Wilson wrote:
As soon as that is done, you've got a data race with the other
existing unshared aliases.
You're in @trusted code, that is the whole point. The
On Sun, Oct 21, 2018 at 3:15 PM Neia Neutuladh via Digitalmars-d
wrote:
>
> On Sun, 21 Oct 2018 12:04:16 -0700, Manu wrote:
> > On Sun, Oct 21, 2018 at 12:00 PM Timon Gehr via Digitalmars-d
> > wrote:
> >> Note that there may well be a good way to get the good properties of MP
> >> without
On 21.10.18 20:46, Manu wrote:
Shared data is only useful if, at some point, it is read/written, presumably by
casting it to unshared in @trusted code. As soon as that is done, you've got a
data race with the other existing unshared aliases.
If such a race is possible, then the @trusted
On Sun, Oct 21, 2018 at 2:35 PM Walter Bright via Digitalmars-d
wrote:
>
> On 10/21/2018 2:08 PM, Walter Bright wrote:
> > On 10/21/2018 12:20 PM, Nicholas Wilson wrote:
> >> Yes, but the problem you describe is arises from implicit conversion in the
> >> other direction, which is not part of the
On Sun, Oct 21, 2018 at 11:31 AM Manu wrote:
>
> On Sun., 21 Oct. 2018, 2:55 am Walter Bright via Digitalmars-d,
> wrote:
> >
> > On 10/20/2018 11:24 AM, Manu wrote:
> > > This is an unfair dismissal.
> >
> > It has nothing at all to do with fairness. It is about what the type system
> >
On Sunday, 21 October 2018 at 22:12:18 UTC, Neia Neutuladh wrote:
On Sun, 21 Oct 2018 12:04:16 -0700, Manu wrote:
On Sun, Oct 21, 2018 at 12:00 PM Timon Gehr via Digitalmars-d
wrote:
Note that there may well be a good way to get the good
properties of MP without breaking the type system, but
On Sunday, 21 October 2018 at 21:32:14 UTC, Walter Bright wrote:
On 10/21/2018 2:08 PM, Walter Bright wrote:
On 10/21/2018 12:20 PM, Nicholas Wilson wrote:
Yes, but the problem you describe is arises from implicit
conversion in the other direction, which is not part of the
proposal.
It's
On Sun, 21 Oct 2018 12:04:16 -0700, Manu wrote:
> On Sun, Oct 21, 2018 at 12:00 PM Timon Gehr via Digitalmars-d
> wrote:
>> Note that there may well be a good way to get the good properties of MP
>> without breaking the type system, but MP itself is not good because it
>> breaks @safe.
>
> Show
On 10/21/2018 2:08 PM, Walter Bright wrote:
On 10/21/2018 12:20 PM, Nicholas Wilson wrote:
Yes, but the problem you describe is arises from implicit conversion in the
other direction, which is not part of the proposal.
It's Manu's example.
Then I don't know what the proposal is. Pieces of
On 10/21/2018 12:20 PM, Nicholas Wilson wrote:
Yes, but the problem you describe is arises from implicit conversion in the
other direction, which is not part of the proposal.
It's Manu's example.
On Sunday, 21 October 2018 at 19:22:45 UTC, Manu wrote:
On Sun, Oct 21, 2018 at 5:50 AM Stanislav Blinov via
Digitalmars-d wrote:
Because the whole reason to have `shared` is to avoid the
extraneous checks that you mentioned above,
No, it is to assure that you write correct not-broken
On Sunday, 21 October 2018 at 19:07:37 UTC, Nicholas Wilson wrote:
On Sunday, 21 October 2018 at 09:50:09 UTC, Walter Bright wrote:
Your proposal makes that impossible because the compiler would
allow unshared data to be implicitly typed as shared.
Yes, but not the other way around.
Whoops
On Sun, Oct 21, 2018 at 5:50 AM Stanislav Blinov via Digitalmars-d
wrote:
>
> On Sunday, 21 October 2018 at 05:47:14 UTC, Manu wrote:
>
> >> And yet, if we're lucky, we get
> >> a consistent instacrash. If we're unlucky, we get memory
> >> corruption, or an unsolicited write to another currently
On Sunday, 21 October 2018 at 18:45:15 UTC, Walter Bright wrote:
I'd like to add that if the compiler can prove that a T* points
to a unique T, then it can be implicitly cast to shared(T)*.
And it does so, like the result of .dup can be so converted.
This can be achieved by using the unique
On Sunday, 21 October 2018 at 09:50:09 UTC, Walter Bright wrote:
Manu's Proposal ---
@safe:
int i;
int* a =
StartNewThread(a); // Compiles! Coder has no idea!
... in the new thread ...
void StartOfNewThread(shared(int)* b) {
... we have two threads accessing 'i',
one thinks it is
On Sun, Oct 21, 2018 at 12:00 PM Timon Gehr via Digitalmars-d
wrote:
>
> On 21.10.18 17:54, Nicholas Wilson wrote:
> >
> >> As soon as that is done, you've got a data race with the other
> >> existing unshared aliases.
> >
> > You're in @trusted code, that is the whole point. The onus is on the
>
On 21.10.18 17:54, Nicholas Wilson wrote:
As soon as that is done, you've got a data race with the other
existing unshared aliases.
You're in @trusted code, that is the whole point. The onus is on the
programmer to make that correct, same with regular @safe/@trusted@system
code.
Not all
I'd like to add that if the compiler can prove that a T* points to a unique T,
then it can be implicitly cast to shared(T)*. And it does so, like the result of
.dup can be so converted.
On Sun, Oct 21, 2018 at 3:00 AM Walter Bright via Digitalmars-d
wrote:
>
> On 10/20/2018 11:08 AM, Nicholas Wilson wrote:
> > You can if no-one else writes to it, which is the whole point of Manu's
> > proposal. Perhaps it should be const shared instead of shared but still.
>
> There is no
On Sun., 21 Oct. 2018, 2:55 am Walter Bright via Digitalmars-d,
wrote:
>
> On 10/20/2018 11:24 AM, Manu wrote:
> > This is an unfair dismissal.
>
> It has nothing at all to do with fairness. It is about what the type system
> guarantees in @safe code. To repeat, the current type system guarantees
On Sat, 20 Oct 2018 22:47:14 -0700, Manu wrote:
> Looking at the meat of the program; you open a file, and distribute it
> to do accesses (I presume?)
> Naturally, this is a really weird thing to do, because even if the API
> is threadsafe such that it doesn't crash and reads/writes are
>
On Sunday, 21 October 2018 at 09:58:18 UTC, Walter Bright wrote:
On 10/20/2018 11:08 AM, Nicholas Wilson wrote:
You can if no-one else writes to it, which is the whole point
of Manu's proposal. Perhaps it should be const shared instead
of shared but still.
There is no purpose whatsoever to
On Sunday, 21 October 2018 at 13:24:49 UTC, Stanislav Blinov
wrote:
On Sunday, 21 October 2018 at 11:25:16 UTC, aliak wrote:
When I say ok, I mean assuming the implementer actually wrote
correct code. This applies to any shared method today as well.
This ("ok") can only be achieved if the
On Sunday, 21 October 2018 at 12:45:43 UTC, Stanislav Blinov
wrote:
On Sunday, 21 October 2018 at 05:47:14 UTC, Manu wrote:
On Sat, Oct 20, 2018 at 10:10 AM Stanislav Blinov via
Digitalmars-d wrote:
Synchronized with what? You still have `a`, which isn't
`shared` and doesn't require any
On Sunday, 21 October 2018 at 09:58:18 UTC, Walter Bright wrote:
On 10/20/2018 11:08 AM, Nicholas Wilson wrote:
You can if no-one else writes to it, which is the whole point
of Manu's proposal. Perhaps it should be const shared instead
of shared but still.
There is no purpose whatsoever to
On Sunday, 21 October 2018 at 09:50:09 UTC, Walter Bright wrote:
On 10/20/2018 11:24 AM, Manu wrote:
This is an unfair dismissal.
It has nothing at all to do with fairness. It is about what the
type system guarantees in @safe code. To repeat, the current
type system guarantees in @safe code
On Sunday, 21 October 2018 at 11:25:16 UTC, aliak wrote:
On Saturday, 20 October 2018 at 16:41:41 UTC, Stanislav Blinov
wrote:
Those are not "ok". They're only "ok" under Manu's proposal so
long as the author of C promises (via documentation) that
that's indeed "ok". There can be no
On Sunday, 21 October 2018 at 05:47:14 UTC, Manu wrote:
On Sat, Oct 20, 2018 at 10:10 AM Stanislav Blinov via
Digitalmars-d wrote:
Synchronized with what? You still have `a`, which isn't
`shared` and doesn't require any atomic access or
synchronization. At this point it doesn't matter if
On Saturday, 20 October 2018 at 16:41:41 UTC, Stanislav Blinov
wrote:
Those are not "ok". They're only "ok" under Manu's proposal so
long as the author of C promises (via documentation) that
that's indeed "ok". There can be no statically-enforced
guarantees that those calls are "ok", or that
On Sunday, 21 October 2018 at 09:58:18 UTC, Walter Bright wrote:
On 10/20/2018 11:08 AM, Nicholas Wilson wrote:
You can if no-one else writes to it, which is the whole point
of Manu's proposal. Perhaps it should be const shared instead
of shared but still.
There is no purpose whatsoever to
On 10/20/2018 11:08 AM, Nicholas Wilson wrote:
You can if no-one else writes to it, which is the whole point of Manu's
proposal. Perhaps it should be const shared instead of shared but still.
There is no purpose whatsoever to data that can be neither read nor written.
Shared data is only
On 21/10/2018 10:41 PM, Manu wrote:
On Sun., 21 Oct. 2018, 2:05 am Walter Bright via Digitalmars-d,
mailto:digitalmars-d@puremagic.com>> wrote:
On 10/20/2018 11:30 AM, Manu wrote:
> You can write an invalid program in any imaginable number of ways;
> that's just not an
On 10/20/2018 11:24 AM, Manu wrote:
This is an unfair dismissal.
It has nothing at all to do with fairness. It is about what the type system
guarantees in @safe code. To repeat, the current type system guarantees in @safe
code that T* and shared(T)* do not point to the same memory location.
On Sun., 21 Oct. 2018, 2:05 am Walter Bright via Digitalmars-d, <
digitalmars-d@puremagic.com> wrote:
> On 10/20/2018 11:30 AM, Manu wrote:
> > You can write an invalid program in any imaginable number of ways;
> > that's just not an interesting discussion.
>
> What we're discussing is not an
On Sunday, 21 October 2018 at 09:04:34 UTC, Walter Bright wrote:
On 10/20/2018 11:30 AM, Manu wrote:
You can write an invalid program in any imaginable number of
ways;
that's just not an interesting discussion.
What we're discussing is not an invalid program, but what
guarantees the type
On 10/20/2018 11:30 AM, Manu wrote:
You can write an invalid program in any imaginable number of ways;
that's just not an interesting discussion.
What we're discussing is not an invalid program, but what guarantees the type
system can provide.
D's current type system guarantees that a T*
On Sat, Oct 20, 2018 at 10:10 AM Stanislav Blinov via Digitalmars-d
wrote:
>
> On Saturday, 20 October 2018 at 16:48:05 UTC, Nicholas Wilson
> wrote:
> > On Saturday, 20 October 2018 at 09:04:17 UTC, Walter Bright
> > wrote:
> >> On 10/19/2018 11:18 PM, Manu wrote:
> >>> The reason I ask is
On Saturday, 20 October 2018 at 18:30:59 UTC, Manu wrote:
On Sat, Oct 20, 2018 at 9:45 AM Stanislav Blinov via
Digitalmars-d wrote:
On Saturday, 20 October 2018 at 16:18:53 UTC, aliak wrote:
> class C {
> void f();
> void g() shared;
> }
Those are not "ok". They're only "ok" under
On Sat, Oct 20, 2018 at 9:45 AM Stanislav Blinov via Digitalmars-d
wrote:
>
> On Saturday, 20 October 2018 at 16:18:53 UTC, aliak wrote:
>
> > class C {
> > void f();
> > void g() shared;
> > }
> >
> > void t1(shared C c) {
> > c.g; // ok
> > c.f; // error
> > }
> >
> > void t2(shared C
On Sat, Oct 20, 2018 at 2:05 AM Walter Bright via Digitalmars-d
wrote:
>
> On 10/19/2018 11:18 PM, Manu wrote:
> > The reason I ask is because, by my definition, if you have:
> > int* a;
> > shared(int)* b = a;
> >
> > While you have 2 numbers that address the same data, it is not actually
> >
On Saturday, 20 October 2018 at 17:06:22 UTC, Stanislav Blinov
wrote:
On Saturday, 20 October 2018 at 16:48:05 UTC, Nicholas Wilson
wrote:
On Saturday, 20 October 2018 at 09:04:17 UTC, Walter Bright
wrote:
by code that believes it is unshared
you cannot `@safe`ly modify the memory through
On Saturday, 20 October 2018 at 16:41:41 UTC, Stanislav Blinov
wrote:
On Saturday, 20 October 2018 at 16:18:53 UTC, aliak wrote:
class C {
void f();
void g() shared;
}
void t1(shared C c) {
c.g; // ok
c.f; // error
}
void t2(shared C c) {
c.g; // ok
c.f; // error
}
auto c = new
On Saturday, 20 October 2018 at 16:48:05 UTC, Nicholas Wilson
wrote:
On Saturday, 20 October 2018 at 09:04:17 UTC, Walter Bright
wrote:
On 10/19/2018 11:18 PM, Manu wrote:
The reason I ask is because, by my definition, if you have:
int* a;
shared(int)* b = a;
While you have 2 numbers that
On Saturday, 20 October 2018 at 09:04:17 UTC, Walter Bright wrote:
On 10/19/2018 11:18 PM, Manu wrote:
The reason I ask is because, by my definition, if you have:
int* a;
shared(int)* b = a;
While you have 2 numbers that address the same data, it is not
actually aliased because only `a` can
On Saturday, 20 October 2018 at 16:18:53 UTC, aliak wrote:
class C {
void f();
void g() shared;
}
void t1(shared C c) {
c.g; // ok
c.f; // error
}
void t2(shared C c) {
c.g; // ok
c.f; // error
}
auto c = new C();
spawn(, c);
spawn(, c);
c.f; // ok
c.g; // ok
Those are not
On Saturday, 20 October 2018 at 09:04:17 UTC, Walter Bright wrote:
Somehow, you still have to find a way to give the shared path
access, through a gate or a cast or a lock or whatever. And
then it breaks, because two different threads are accessing the
same data each thinking that data is not
On 10/19/2018 11:18 PM, Manu wrote:
The reason I ask is because, by my definition, if you have:
int* a;
shared(int)* b = a;
While you have 2 numbers that address the same data, it is not actually aliased
because only `a` can access it.
They are aliased, by code that believes it is unshared,
On Fri, Oct 19, 2018 at 9:45 AM Steven Schveighoffer via Digitalmars-d
wrote:
>
> On 10/18/18 9:09 PM, Manu wrote:
> > On Thu, Oct 18, 2018 at 5:30 PM Timon Gehr via Digitalmars-d
> > wrote:
> >>
> >> On 18.10.18 23:34, Erik van Velzen wrote:
> >>> If you have an object which can be used in both
On Fri., 19 Oct. 2018, 3:10 am Walter Bright via Digitalmars-d, <
digitalmars-d@puremagic.com> wrote:
> On 10/17/2018 12:20 AM, Manu wrote:
> > What does it mean 'aliased' precisely?
>
> Aliasing means there are two paths to the same piece of data. That could
> be two
> pointers pointing to the
On Friday, 19 October 2018 at 18:00:47 UTC, Atila Neves wrote:
Because int or int* does not have threadsafe member functions.
https://dlang.org/phobos/core_atomic.html
Atomic and thread-safe are two very different concepts.
Thread-safe is more of an ecosystem thing - if there are ways to
On 20/10/2018 2:07 AM, Dominikus Dittes Scherkl wrote:
This document provide no reasoning about what usecases it supports:
It was a basic idea of mine... It was never meant to be PR'd.
On Thursday, 18 October 2018 at 21:24:53 UTC, jmh530 wrote:
On Thursday, 18 October 2018 at 17:17:37 UTC, Atila Neves wrote:
[snip]
Assuming this world... how do you use shared?
https://github.com/atilaneves/fearless
I had posted your library before to no response...
I had two
On Thursday, 18 October 2018 at 19:04:58 UTC, Erik van Velzen
wrote:
On Thursday, 18 October 2018 at 17:47:29 UTC, Stanislav Blinov
wrote:
On Thursday, 18 October 2018 at 17:17:37 UTC, Atila Neves
wrote:
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
Assuming the rules above: "can't
On Fri., 19 Oct. 2018, 6:10 am Dominikus Dittes Scherkl via Digitalmars-d, <
digitalmars-d@puremagic.com> wrote:
> On Friday, 19 October 2018 at 06:25:00 UTC, rikki cattermole
> wrote:
> > On 19/10/2018 7:09 PM, Norm wrote:
>
> > [0]
> >
On 10/18/18 9:09 PM, Manu wrote:
On Thu, Oct 18, 2018 at 5:30 PM Timon Gehr via Digitalmars-d
wrote:
On 18.10.18 23:34, Erik van Velzen wrote:
If you have an object which can be used in both a thread-safe and a
thread-unsafe way that's a bug or code smell.
Then why do you not just make all
On Friday, 19 October 2018 at 06:25:00 UTC, rikki cattermole
wrote:
On 19/10/2018 7:09 PM, Norm wrote:
[0]
https://github.com/rikkimax/DIPs/blob/shared/DIPs/DIP1xxx-RC2.md
This document provide no reasoning about what usecases it
supports:
Is it possible to create objects that are shared
On 10/17/2018 12:20 AM, Manu wrote:
What does it mean 'aliased' precisely?
Aliasing means there are two paths to the same piece of data. That could be two
pointers pointing to the same data, or one pointer to a variable that is
accessible by name.
It doesn't really give us
anything in
On 19/10/2018 9:02 PM, Walter Bright wrote:
On 10/17/2018 4:29 AM, jmh530 wrote:
Isn't that also true for isolated data (data that only allows one alias)?
That's colloquially called "unique" data. And yes, it is also true for
that. That's why casting the return value of malloc() to 'shared'
On 10/17/2018 4:29 AM, jmh530 wrote:
Isn't that also true for isolated data (data that only allows one alias)?
That's colloquially called "unique" data. And yes, it is also true for that.
That's why casting the return value of malloc() to 'shared' is safe. It's just
that the language has no
On 19/10/2018 7:09 PM, Norm wrote:
There's another way; Stanislav isn't one you need to convince so if that
particular discussion is unproductive and disruptive just ignore it. I.e
technical discussions should be robust but once they become personal
just ignore that input and move on. Isn't
On Friday, 19 October 2018 at 02:20:22 UTC, Manu wrote:
On Thu., 18 Oct. 2018, 7:10 pm Stanislav Blinov via
Digitalmars-d, < digitalmars-d@puremagic.com> wrote:
On Friday, 19 October 2018 at 01:53:00 UTC, Manu wrote:
> This is a red-herring.
> In short, he made up this issue, it doesn't
On Friday, 19 October 2018 at 02:20:22 UTC, Manu wrote:
I've given use cases constantly, about taking object ownership,
promotions, and distribution for periods (think parallel for),
Manu, you haven't shown *any* code in which conversion from
mutable to shared, an *implicit* one at that, was
1 - 100 of 266 matches
Mail list logo
