On Friday, 19 October 2018 at 15:46:20 UTC, Stanislav Blinov
wrote:
On Friday, 19 October 2018 at 13:40:54 UTC, Dominikus Dittes
Scherkl wrote:
Conflating "shared" and "threadsave" in that manner was, I
think, the biggest mistake of your proposal.
He talked about it in a previous thread, and g
On Thursday, 18 October 2018 at 16:21:00 UTC, Kai wrote:
On Thursday, 18 October 2018 at 07:51:07 UTC, Andre Pany wrote:
On Thursday, 18 October 2018 at 00:24:29 UTC, Kai wrote:
On Wednesday, 17 October 2018 at 17:44:34 UTC, Adam D. Ruppe
wrote:
[...]
Hmm - wish it was so. When architecture
On Friday, 19 October 2018 at 23:34:01 UTC, Atila Neves wrote:
On Thursday, 20 September 2018 at 12:48:13 UTC, Steven
Schveighoffer wrote:
How is the exception destroyed when dip1008 is enabled?
Apparently, it isn't. Which renders dip1008 pretty much useless
since we could already use static
On Friday, 19 October 2018 at 18:11:50 UTC, Manu wrote:
On Fri, Oct 19, 2018 at 6:45 AM Dominikus Dittes Scherkl via
Digitalmars-d wrote:
On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote:
> [...] What issues am I failing to address?
[...] Another point is the part of "how
On Thursday, 20 September 2018 at 12:48:13 UTC, Steven
Schveighoffer wrote:
On 9/20/18 6:48 AM, Atila Neves wrote:
On Wednesday, 19 September 2018 at 21:16:00 UTC, Steven
Schveighoffer wrote:
Given dip1008, we now can throw exceptions inside @nogc code!
This is really cool, and helps make code
On Fri, Oct 19, 2018 at 02:41:48PM -0700, H. S. Teoh via Digitalmars-d wrote:
[...]
> In the meantime, is there a particular version of the NDK that I
> should use? Currently I have android-ndk-r13b-linux-x86_64.zip
> installed. Will it work?
[...]
Haha, I feel so silly now. NDK r13b
On Fri, Oct 19, 2018 at 02:41:48PM -0700, H. S. Teoh via Digitalmars-d wrote:
[...]
> I tried ldc-build-runtime with --ninja and it came back with a bunch of
> errors about "cortex-a8" being an unsupported target, and then
> segfaulted. So I'm going to try the "
On Fri, Oct 19, 2018 at 08:54:25PM +, Joakim via Digitalmars-d wrote:
[...]
> Also, if you're using a system-provided LDC, it may not support Android, if
> it wasn't built against our slightly tweaked llvm:
>
> https://github.com/ldc-developers/llvm
>
> In tha
Now that
https://github.com/dlang/phobos/pull/6411
has been merged and DMD stable soon has the new
__traits(isZeroInit, T)
found here
https://dlang.org/changelog/2.083.0.html#isZeroInit
are there more zero-initializations that can be optimized in
std.experimental.allocator?
On Friday, 19 October 2018 at 20:50:36 UTC, Joakim wrote:
On Wednesday, 17 October 2018 at 21:23:21 UTC, H. S. Teoh wrote:
I'm trying to follow the instructions on this page:
https://wiki.dlang.org/Build_D_for_Android
[...]
Hmm, that's weird: can you extract the full compiler command
On Wednesday, 17 October 2018 at 21:23:21 UTC, H. S. Teoh wrote:
I'm trying to follow the instructions on this page:
https://wiki.dlang.org/Build_D_for_Android
[...]
Hmm, that's weird: can you extract the full compiler command for
that file? For example, if you use Ninja, by appendin
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
do
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 Fri, Oct 19, 2018 at 06:34:50PM +, Joakim via Digitalmars-d wrote:
> On Thursday, 18 October 2018 at 19:37:24 UTC, H. S. Teoh wrote:
[...]
> > Eventually I resorted to generating Java code from D for some fo the
> > most painful repetitive parts, and the way things a
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 questions,
On Thursday, 18 October 2018 at 19:37:24 UTC, H. S. Teoh wrote:
On Thu, Oct 18, 2018 at 07:09:42PM +, Patrick Schluter via
Digitalmars-d wrote: [...]
I often have the impression that a lot of things are going
slower than necessary because a mentality where the perfect is
in the way of good
On Fri, Oct 19, 2018 at 6:45 AM Dominikus Dittes Scherkl via
Digitalmars-d wrote:
>
> On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote:
> > On Wednesday, 17 October 2018 at 22:56:26 UTC, H. S. Teoh wrote:
> >> What cracks me up with Manu's proposal is that it
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 re
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]
> > https://github.com/rikki
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 mak
On Friday, 19 October 2018 at 13:40:54 UTC, Dominikus Dittes
Scherkl wrote:
On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote:
On Wednesday, 17 October 2018 at 22:56:26 UTC, H. S. Teoh
wrote:
What cracks me up with Manu's proposal is that it is its
simplicity and lack of ambition that is
On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote:
On Wednesday, 17 October 2018 at 22:56:26 UTC, H. S. Teoh wrote:
What cracks me up with Manu's proposal is that it is its
simplicity and lack of ambition that is criticized the most.
shared is a clusterfuck, according to what I gathered
Hi,
So for those of you who have contributed to D on GitHub in the
last few months, you might have noticed the new Buildkite CI
status checks.
tl;dr:
- it's the replacement for the Jenkins project tester (which has
been deactivated ~ three months ago)
- it allows us to add our own agents to
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 Wednesday, 17 October 2018 at 13:15:44 UTC, bachmeier wrote:
I can definitely see that. I wanted to write a GUI program some
time ago and looked at GtkD. It wasn't easy to see where to
start with GtkD, and I eventually ended up running a local web
server and creating the GUI in the browse
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 prac
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' i
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 w
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 alw
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
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
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 exist.
> > This is j
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 exist.
This is just hot air, and only strengthen my conviction.
Produce, or drop this presumptious crap.
You are an obscene person. I'm out.
Oooh, I'm srry, come
On Thu, Oct 18, 2018 at 6:50 PM Stanislav Blinov via Digitalmars-d
wrote:
>
> On Friday, 19 October 2018 at 01:22:53 UTC, Manu wrote:
> > On Thu, Oct 18, 2018 at 3:10 PM Simen Kjærås via Digitalmars-d
> > wrote:
> >>
> >>
> >> Now, Two very good point
On Friday, 19 October 2018 at 01:22:53 UTC, Manu wrote:
On Thu, Oct 18, 2018 at 3:10 PM Simen Kjærås via Digitalmars-d
wrote:
Now, Two very good points came up in this post, and I think
it's worth stating them again, because they do present
possible issues with MP:
It is easy to re
On Thu, Oct 18, 2018 at 3:10 PM Simen Kjærås via Digitalmars-d
wrote:
>
>
> Now, Two very good points came up in this post, and I think it's
> worth stating them again, because they do present possible issues
> with MP:
It is easy to respond to these.
> 1) How does MP d
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 mak
On Friday, 19 October 2018 at 00:29:01 UTC, Timon Gehr 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 members shared? Because with
Manu's propo
On Thu, Oct 18, 2018 at 3:40 PM Steven Schveighoffer via Digitalmars-d
wrote:
>
> On 10/18/18 5:22 PM, Manu wrote:
> > On Thu, Oct 18, 2018 at 12:15 PM Steven Schveighoffer via
> > Digitalmars-d wrote:
> >>
> >> On 10/18/18 2:55 PM, Manu wrote:
> >
On Friday, 19 October 2018 at 00:36:11 UTC, Timon Gehr wrote:
On 19.10.18 02:29, Stanislav Blinov wrote:
On Thursday, 18 October 2018 at 23:47:56 UTC, Timon Gehr wrote:
I'm pretty sure you will have to allow operations on shared
local variables. Otherwise, how are you ever going to use a
shar
On 19.10.18 02:29, Stanislav Blinov wrote:
On Thursday, 18 October 2018 at 23:47:56 UTC, Timon Gehr wrote:
I'm pretty sure you will have to allow operations on shared local
variables. Otherwise, how are you ever going to use a shared(C)? You
can't even call a shared method on it because it inv
On Thursday, 18 October 2018 at 23:47:56 UTC, Timon Gehr wrote:
I'm pretty sure you will have to allow operations on shared
local variables. Otherwise, how are you ever going to use a
shared(C)? You can't even call a shared method on it because it
involves reading the reference.
Because you
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 members shared? Because with Manu's
proposal, as soon as you have a shared method, all members effective
On 18.10.18 20:26, Steven Schveighoffer wrote:
i = 1;
int x = i;
shared int y = i;
This should be fine, y is not shared when being created.
However, this still is allowed, and shouldn't be:
y = 5;
-Steve
I'm pretty sure you will have to allow operations on shared local
variables. Otherwi
On Thursday, 18 October 2018 at 22:09:02 UTC, Manu wrote:
The 2 different strategies are 2 different worlds, one is my
proposal,
the other is more like what we have now. They are 2 different
rule-sets.
You are super-attached to some presumptions, and appear to
refuse to
analyse the proposal f
On Thursday, 18 October 2018 at 22:08:14 UTC, Simen Kjærås wrote:
On Thursday, 18 October 2018 at 16:31:02 UTC, Stanislav Blinov
Now, if the compiler generated above in the presence of any
`shared` members or methods, then we could begin talking about
it being threadsafe...
Again, this is g
On 10/18/18 5:22 PM, Manu wrote:
On Thu, Oct 18, 2018 at 12:15 PM Steven Schveighoffer via
Digitalmars-d wrote:
On 10/18/18 2:55 PM, Manu wrote:
On Thu, Oct 18, 2018 at 7:20 AM Steven Schveighoffer via Digitalmars-d
wrote:
On 10/18/18 10:11 AM, Simen Kjærås wrote:
On Thursday, 18 October
On Thursday, 18 October 2018 at 21:51:52 UTC, aliak wrote:
On Thursday, 18 October 2018 at 18:12:03 UTC, Stanislav Blinov
wrote:
On Thursday, 18 October 2018 at 18:05:51 UTC, aliak wrote:
Right, but the argument is a shared int*, so from what I've
understood... you can't do anything with it si
On Thursday, 18 October 2018 at 16:31:02 UTC, Stanislav Blinov
wrote:
You contradict yourself and don't even notice it. Per your
rules, the way to open that locked box is have shared methods
that access data via casting. Also per your rules, there is
absolutely no way for the programmer to cont
On Thursday, 18 October 2018 at 21:54:55 UTC, Stanislav Blinov
wrote:
Manu, Erik, Simen... In what world can a person consciously say
"casting is unsafe", and yet at the same time claim that
*implicit casting* is safe? What the actual F, guys?
In a world where the implicit casting always ends
On Thu, Oct 18, 2018 at 2:55 PM Stanislav Blinov via Digitalmars-d
wrote:
>
> Manu, Erik, Simen... In what world can a person consciously say
> "casting is unsafe", and yet at the same time claim that
> *implicit casting* is safe? What the actual F, guys?
Implicit casting e
On Thursday, 18 October 2018 at 14:19:41 UTC, Steven
Schveighoffer wrote:
On 10/18/18 10:11 AM, Simen Kjærås wrote:
On Thursday, 18 October 2018 at 13:35:22 UTC, Steven
Schveighoffer wrote:
struct ThreadSafe
{
private int x;
void increment()
{
++x; // I know this is not shared, s
Manu, Erik, Simen... In what world can a person consciously say
"casting is unsafe", and yet at the same time claim that
*implicit casting* is safe? What the actual F, guys?
On Thursday, 18 October 2018 at 18:12:03 UTC, Stanislav Blinov
wrote:
On Thursday, 18 October 2018 at 18:05:51 UTC, aliak wrote:
Right, but the argument is a shared int*, so from what I've
understood... you can't do anything with it since it has no
shared members. i.e. you can't read or write
On Thu, Oct 18, 2018 at 2:40 PM Erik van Velzen via Digitalmars-d
wrote:
>
> Manu I'm also making a plea for you to write a document with your
> proposal which aggregates all relevant examples and objections.
> Then you can easily refer to it and we can introduce ppl to idea
&g
Manu I'm also making a plea for you to write a document with your
proposal which aggregates all relevant examples and objections.
Then you can easily refer to it and we can introduce ppl to idea
without reading a megathread.
On Thursday, 18 October 2018 at 20:07:54 UTC, Stanislav Blinov
wrote:
On Thursday, 18 October 2018 at 19:51:17 UTC, Erik van Velzen
wrote:
On Thursday, 18 October 2018 at 19:26:39 UTC, Stanislav Blinov
Manu said clearly that the receiving thread won't be able to
read or write the pointer.
Y
On Thursday, 18 October 2018 at 21:14:54 UTC, Stanislav Blinov
wrote:
On Thursday, 18 October 2018 at 20:59:59 UTC, Erik van Velzen
wrote:
[...]
Quite a simple reason: it was years ago, however old you are
now you were younger and less experienced, and probably didn't
understand something ba
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 questions, if you'll indulge me.
The first is perhaps more wrt automem
On Thu, Oct 18, 2018 at 1:10 PM Stanislav Blinov via Digitalmars-d
wrote:
>
> On Thursday, 18 October 2018 at 19:51:17 UTC, Erik van Velzen
> wrote:
> > On Thursday, 18 October 2018 at 19:26:39 UTC, Stanislav Blinov
>
> >>> Manu said clearly that the receiving thre
On Thu, Oct 18, 2018 at 12:15 PM Steven Schveighoffer via
Digitalmars-d wrote:
>
> On 10/18/18 2:55 PM, Manu wrote:
> > On Thu, Oct 18, 2018 at 7:20 AM Steven Schveighoffer via Digitalmars-d
> > wrote:
> >>
> >> On 10/18/18 10:11 AM, Simen Kjærås wrote:
>
On Thu, Oct 18, 2018 at 12:10 PM Steven Schveighoffer via
Digitalmars-d wrote:
>
> On 10/18/18 2:24 PM, Manu wrote:
> > I understand your argument, and I used to think this too... but I
> > concluded differently for 1 simple reason: usability.
>
> You have not demonstra
On Thursday, 18 October 2018 at 20:59:59 UTC, Erik van Velzen
wrote:
Let me start by saying I'm willing to admit that I was
factually wrong.
Also keep in mind that "me having an impression" is something
that is can't be independently verified and you'll have to take
my at my word. Just that
Let me start by saying I'm willing to admit that I was factually
wrong.
Also keep in mind that "me having an impression" is something
that is can't be independently verified and you'll have to take
my at my word. Just that the exact reason for that impression was
lost to the sands of time.
On Thursday, 18 October 2018 at 19:09:42 UTC, Patrick Schluter
wrote:
On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote:
Elaborate on this... It's clearly over-ambitious if anything.
What issues am I failing to address? I'm creating a situation
where using
shared has a meaning, is safe,
On Thursday, 18 October 2018 at 20:10:18 UTC, Erik van Velzen
wrote:
When shared stood up in its current form, expectation was made
"this will be threadsafe automatically - we'll figure out how
in the future".
It never was like that. At all. I don't think either Walter or
Andrei are idiots
On Thursday, 18 October 2018 at 19:51:17 UTC, Erik van Velzen
wrote:
On Thursday, 18 October 2018 at 19:26:39 UTC, Stanislav Blinov
Manu said clearly that the receiving thread won't be able to
read or write the pointer.
Yes it will, by casting `shared` away. *Just like* his
proposed "wrap e
On Thursday, 18 October 2018 at 19:26:39 UTC, Stanislav Blinov
wrote:
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:
Doesn't work. No matter what you show Manu or Simen here they
think it's just a bad
On Thu, Oct 18, 2018 at 07:26:08PM +, MDtox via Digitalmars-d wrote:
> How to convert decimal and string to binary?
What exactly do you mean by "binary"? If you mean convert a string to a
numerical type, use std.conv.to:
import std.conv : to;
auto x = "1234
On Thu, Oct 18, 2018 at 07:09:42PM +, Patrick Schluter via Digitalmars-d
wrote:
[...]
> I often have the impression that a lot of things are going slower than
> necessary because a mentality where the perfect is in the way of good.
That is indeed an all-too-frequent malady around these
How to convert decimal and string to binary?
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 re
On 10/18/18 2:42 PM, Stanislav Blinov wrote:
On Thursday, 18 October 2018 at 18:26:27 UTC, Steven Schveighoffer wrote:
On 10/18/18 1:47 PM, 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:
1. shared
On 10/18/18 2:55 PM, Manu wrote:
On Thu, Oct 18, 2018 at 7:20 AM Steven Schveighoffer via Digitalmars-d
wrote:
On 10/18/18 10:11 AM, Simen Kjærås wrote:
On Thursday, 18 October 2018 at 13:35:22 UTC, Steven Schveighoffer wrote:
struct ThreadSafe
{
private int x;
void increment
On Thursday, 18 October 2018 at 17:01:46 UTC, Stanislav Blinov
wrote:
On Thursday, 18 October 2018 at 16:31:33 UTC, Vijay Nayar wrote:
Imagine a simple algorithm that does logic on very long
numbers, split into bytes. One multi-threaded implementation
may use 4 threads. The first operating o
On 10/18/18 2:59 PM, Manu wrote:
On Thu, Oct 18, 2018 at 7:20 AM Steven Schveighoffer via Digitalmars-d
wrote:
On 10/18/18 10:11 AM, Simen Kjærås wrote:
a.increment(); // unsafe, non-shared method call
}
When a.increment() is being called, you have no idea if anyone else is
using the
On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote:
On Thu., 18 Oct. 2018, 5:05 am Patrick Schluter via
Digitalmars-d, < digitalmars-d@puremagic.com> wrote:
On Wednesday, 17 October 2018 at 22:56:26 UTC, H. S. Teoh
wrote:
>> If something might be used by someone else it&
On 10/18/18 2:24 PM, Manu wrote:
I understand your argument, and I used to think this too... but I
concluded differently for 1 simple reason: usability.
You have not demonstrated why your proposal is usable, and the proposal
to simply make shared not accessible while NOT introducing implicit
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 read or write to members",
and the understanding that `shared` methods
On Thursday, 18 October 2018 at 18:24:47 UTC, Manu wrote:
I have demonstrated these usability considerations in
production. I am
confident it's the right balance.
Then convince us. So far you haven't.
I propose:
1. Normal people don't write thread-safety, a very small
number of
unusual pe
On Thu, Oct 18, 2018 at 7:20 AM Steven Schveighoffer via Digitalmars-d
wrote:
>
> On 10/18/18 10:11 AM, Simen Kjærås wrote:
> > a.increment(); // unsafe, non-shared method call
> > }
> >
> > When a.increment() is being called, you have no idea if anyone else is
On Thu, Oct 18, 2018 at 7:20 AM Steven Schveighoffer via Digitalmars-d
wrote:
>
> On 10/18/18 10:11 AM, Simen Kjærås wrote:
> > On Thursday, 18 October 2018 at 13:35:22 UTC, Steven Schveighoffer wrote:
> >> struct ThreadSafe
> >> {
> >>
On Thu, Oct 18, 2018 at 6:50 AM Steven Schveighoffer via Digitalmars-d
wrote:
>
> On 10/18/18 9:35 AM, Steven Schveighoffer wrote:
> >
> > struct NotThreadsafe
> > {
> >private int x;
> >void local()
> >{
> > ++x; // <-
On Thursday, 18 October 2018 at 18:26:27 UTC, Steven
Schveighoffer wrote:
On 10/18/18 1:47 PM, 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:
1. shared should behave exactly like const, except in
On 10/18/18 1:47 PM, 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:
1. shared should behave exactly like const, except in addition to
inhibiting write access, it also inhibits read access.
How is
On Thu, Oct 18, 2018 at 6:40 AM Steven Schveighoffer via Digitalmars-d
wrote:
>
> On 10/17/18 10:26 PM, Manu wrote:
> > On Wed, Oct 17, 2018 at 6:50 PM Steven Schveighoffer via Digitalmars-d
> >>
> >> The implicit cast means that you have to look at more than just
On Thursday, 18 October 2018 at 18:05:51 UTC, aliak wrote:
Right, but the argument is a shared int*, so from what I've
understood... you can't do anything with it since it has no
shared members. i.e. you can't read or write to it. No?
Obviously the implementation would cast `shared` away, jus
On Thursday, 18 October 2018 at 17:23:36 UTC, Stanislav Blinov
wrote:
On Thursday, 18 October 2018 at 17:10:03 UTC, aliak wrote:
Out of curiosity, when it comes to primitives, what could you
do under MP in void "atomicInc(shared int*)" that would be
problematic?
void atomicInc(shared int*) {
Pardon the snarkiness, I probably need to get some air from that
other shared thread.
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:
1. shared should behave exactly like const, except in addition
to inhibiting write access, it also inhibits read access.
How is this significantly different from now?
-
On Thursday, 18 October 2018 at 17:43:40 UTC, Steven
Schveighoffer wrote:
On 10/18/18 1:17 PM, Atila Neves wrote:
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
1. shared should behave exactly like const, except in
addition to inhibiting write access, it also inhibits read
access.
H
On 10/18/18 1:17 PM, Atila Neves wrote:
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
1. shared should behave exactly like const, except in addition to
inhibiting write access, it also inhibits read access.
How is this significantly different from now?
-
shared int i
On Thursday, 18 October 2018 at 17:10:03 UTC, aliak wrote:
Out of curiosity, when it comes to primitives, what could you
do under MP in void "atomicInc(shared int*)" that would be
problematic?
void atomicInc(shared int*) {
// i.e. what goes here?
}
1. Anything if int* implicitly converts
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
1. shared should behave exactly like const, except in addition
to inhibiting write access, it also inhibits read access.
How is this significantly different from now?
-
shared int i;
++i;
Error: read-modify-write operatio
On Thursday, 18 October 2018 at 16:31:02 UTC, Stanislav Blinov
wrote:
So again,
void atomicInc(shared int*); // is "not safe", but
void struct_Atomic_int_opUnary_plus_plus(ref shared Atomic); //
is "safe"
just because latter is a "method". And that, by you, is
hunky-dory? Whether it's a meth
On Thursday, 18 October 2018 at 16:31:33 UTC, Vijay Nayar wrote:
Imagine a simple algorithm that does logic on very long
numbers, split into bytes. One multi-threaded implementation
may use 4 threads. The first operating on bytes 0, 4, 8, etc.
The second operating on bytes 1, 5, 9, etc.
I
On Thursday, 18 October 2018 at 13:09:10 UTC, Simen Kjærås wrote:
Well, sorta. But that's not a problem, because you can't do
anything that's not threadsafe to something that's shared.
Yes you can. You silently agree to another function's
assumption that you pass shared data, while actually p
On Wednesday, 17 October 2018 at 21:12:49 UTC, Stefan Koch wrote:
Hi,
reading the other shared thread "shared - i need to be
useful"(https://forum.dlang.org/thread/mailman.4299.1539629222.29801.digitalmar...@puremagic.com)
let me to an important realisation concerning the reason
shareding d
On Thursday, 18 October 2018 at 07:51:07 UTC, Andre Pany wrote:
On Thursday, 18 October 2018 at 00:24:29 UTC, Kai wrote:
On Wednesday, 17 October 2018 at 17:44:34 UTC, Adam D. Ruppe
wrote:
[...]
Hmm - wish it was so. When architecture not specified, the
linker crashes. When it's given, this
On Thu., 18 Oct. 2018, 5:05 am Patrick Schluter via Digitalmars-d, <
digitalmars-d@puremagic.com> wrote:
> On Wednesday, 17 October 2018 at 22:56:26 UTC, H. S. Teoh wrote:
> >> If something might be used by someone else it's better not to
> >> touch it, unless one
201 - 300 of 90926 matches
Mail list logo
