Jump to page: 1 25  
Page
Thread overview
An Issue I Wish To Raise Awareness On
Jul 17, 2017
Jack Stouffer
Jul 17, 2017
Atila Neves
Jul 17, 2017
Jack Stouffer
Jul 18, 2017
Kagamin
Jul 18, 2017
Atila Neves
Jul 18, 2017
Jonathan M Davis
Jul 19, 2017
Kagamin
Jul 19, 2017
Marco Leise
Jul 20, 2017
Kagamin
Jul 25, 2017
Marco Leise
Jul 28, 2017
Kagamin
Jul 29, 2017
Kagamin
Jul 19, 2017
Atila Neves
Jul 19, 2017
Jonathan M Davis
Jul 19, 2017
Atila Neves
Jul 20, 2017
Kagamin
Jul 19, 2017
Jonathan M Davis
Jul 20, 2017
Kagamin
Jul 20, 2017
Jonathan M Davis
Jul 21, 2017
Atila Neves
Jul 21, 2017
Jonathan M Davis
Jul 24, 2017
Atila Neves
Jul 24, 2017
Jonathan M Davis
Jul 25, 2017
Atila Neves
Jul 25, 2017
Kagamin
Jul 20, 2017
Kagamin
Jul 21, 2017
Atila Neves
Jul 21, 2017
Kagamin
Jul 21, 2017
Kagamin
Jul 21, 2017
Moritz Maxeiner
Jul 21, 2017
Atila Neves
Jul 18, 2017
Atila Neves
Jul 19, 2017
Dukc
Jul 19, 2017
Jack Stouffer
Jul 19, 2017
Dukc
Jul 18, 2017
Atila Neves
Jul 18, 2017
Marco Leise
Jul 21, 2017
Atila Neves
Aug 12, 2017
Arek
Aug 14, 2017
Atila Neves
Aug 14, 2017
Arek
Aug 15, 2017
Atila Neves
Aug 14, 2017
Arek
July 17, 2017
TL;DR: Issue 17658 [1] makes using shared very annoying/practically impossible.

Over the weekend, I attempted to fix Issue 15768 [2], which is an underlying problem in the std.stdio.File struct that stops it from closing properly when shared across threads. This is a big problem for users because stdin/out/err are all __gshared File, and are therefore unsafe. This makes for a really annoying situation where writeln("a") is @safe but stderr.writeln("a") isn't.

The obvious solution is to make stdin/out/err shared(File) and modify File to have shared overloads which either lock or use atomic ops safely. When I tried to write said functions, I ran into compilation issues that I couldn't diagnose until I ran across this thread by Atila [3]. The problem is, unlike a constructor, destructors and post-blits can't be overloaded with shared variants. Consider:

```
struct A
{
    this(string a) {}
    this(string a) shared {}

    ~this() {}
    ~this() shared {}

    this(this) {}
    this(this) shared {}
}

void main()
{
    shared f = A("");
}
```

Error: destructor f152.A.~this conflicts with destructor f152.A.~this at /d422/f152.d(6)
Error: function f152.A.__postblit conflicts with function f152.A.__postblit at /d422/f152.d(9)

This is further compounded with this

```
struct A
{
	~this() {}
}

void main()
{
	auto a = A();
	shared b = A();
}
```

Error: non-shared method f585.A.~this is not callable using a shared object

The only way to work around this is to create a new type that is defined as shared struct and copy over all of the code from the original type. This really hobbles shared in any real world context.

I ask that someone who knows the DMD code base could please take a look at this and see if this is something that can be fixed easily and without breakage.

[1] https://issues.dlang.org/show_bug.cgi?id=17658
[2] https://issues.dlang.org/show_bug.cgi?id=15768
[3] https://forum.dlang.org/post/sqazguejrcdtjimtjxtz@forum.dlang.org
July 17, 2017
On Monday, 17 July 2017 at 14:26:19 UTC, Jack Stouffer wrote:
> TL;DR: Issue 17658 [1] makes using shared very annoying/practically impossible.
>
> [...]

I fixed this already, should be in the next release.

Atila
July 17, 2017
On Monday, 17 July 2017 at 17:41:58 UTC, Atila Neves wrote:
> On Monday, 17 July 2017 at 14:26:19 UTC, Jack Stouffer wrote:
>> TL;DR: Issue 17658 [1] makes using shared very annoying/practically impossible.
>>
>> [...]
>
> I fixed this already, should be in the next release.
>
> Atila

Are you sure? Because DMD nightly still errors:

https://run.dlang.io?compiler=dmd-nightly&source=struct%20A%0A%7B%0A%20%20%20%20this(string%20a)%20%7B%7D%0A%20%20%20%20this(string%20a)%20shared%20%7B%7D%0A%0A%20%20%20%20~this()%20%7B%7D%0A%20%20%20%20~this()%20shared%20%7B%7D%0A%0A%20%20%20%20this(this)%20%7B%7D%0A%20%20%20%20this(this)%20shared%20%7B%7D%0A%7D%0A%0Avoid%20main()%0A%7B%0A%20%20%20%20shared%20f%20%3D%20A(%22%22)%3B%0A%7D


(maybe we should remove the ban on URL shorteners for our own sites)
July 18, 2017
On Monday, 17 July 2017 at 19:30:53 UTC, Jack Stouffer wrote:
> On Monday, 17 July 2017 at 17:41:58 UTC, Atila Neves wrote:
>> On Monday, 17 July 2017 at 14:26:19 UTC, Jack Stouffer wrote:
>>> TL;DR: Issue 17658 [1] makes using shared very annoying/practically impossible.
>>>
>>> [...]
>>
>> I fixed this already, should be in the next release.
>>
>> Atila
>
> Are you sure? Because DMD nightly still errors:
>
> https://run.dlang.io?compiler=dmd-nightly&source=struct%20A%0A%7B%0A%20%20%20%20this(string%20a)%20%7B%7D%0A%20%20%20%20this(string%20a)%20shared%20%7B%7D%0A%0A%20%20%20%20~this()%20%7B%7D%0A%20%20%20%20~this()%20shared%20%7B%7D%0A%0A%20%20%20%20this(this)%20%7B%7D%0A%20%20%20%20this(this)%20shared%20%7B%7D%0A%7D%0A%0Avoid%20main()%0A%7B%0A%20%20%20%20shared%20f%20%3D%20A(%22%22)%3B%0A%7D
>
>
> (maybe we should remove the ban on URL shorteners for our own sites)

I think Atila was talking about this one:
struct A
{
	~this() {}
}

void main()
{
	auto a = A();
	shared b = A();
}

https://is.gd/kOYlWY
July 18, 2017
On Tuesday, 18 July 2017 at 11:47:37 UTC, Petar Kirov [ZombineDev] wrote:
> On Monday, 17 July 2017 at 19:30:53 UTC, Jack Stouffer wrote:
>> On Monday, 17 July 2017 at 17:41:58 UTC, Atila Neves wrote:
>>> On Monday, 17 July 2017 at 14:26:19 UTC, Jack Stouffer wrote:
>>>> TL;DR: Issue 17658 [1] makes using shared very annoying/practically impossible.
>>>>
>>>> [...]
>>>
>>> I fixed this already, should be in the next release.
>>>
>>> Atila
>>
>> Are you sure? Because DMD nightly still errors:
>>
>> https://run.dlang.io?compiler=dmd-nightly&source=struct%20A%0A%7B%0A%20%20%20%20this(string%20a)%20%7B%7D%0A%20%20%20%20this(string%20a)%20shared%20%7B%7D%0A%0A%20%20%20%20~this()%20%7B%7D%0A%20%20%20%20~this()%20shared%20%7B%7D%0A%0A%20%20%20%20this(this)%20%7B%7D%0A%20%20%20%20this(this)%20shared%20%7B%7D%0A%7D%0A%0Avoid%20main()%0A%7B%0A%20%20%20%20shared%20f%20%3D%20A(%22%22)%3B%0A%7D
>>
>>
>> (maybe we should remove the ban on URL shorteners for our own sites)
>
> I think Atila was talking about this one:
> struct A
> {
> 	~this() {}
> }
>
> void main()
> {
> 	auto a = A();
> 	shared b = A();
> }
>
> https://is.gd/kOYlWY

https://github.com/dlang/dmd/pull/6752
July 18, 2017
On Tuesday, 18 July 2017 at 11:47:37 UTC, Petar Kirov [ZombineDev] wrote:
> I think Atila was talking about this one:
> struct A
> {
> 	~this() {}
> }
>
> void main()
> {
> 	auto a = A();
> 	shared b = A();
> }

This is strange. There's nothing that suggests that struct A and its destructor is thread-safe, yet compiler assumes it is.
July 18, 2017
On Tuesday, 18 July 2017 at 11:47:37 UTC, Petar Kirov [ZombineDev] wrote:
> On Monday, 17 July 2017 at 19:30:53 UTC, Jack Stouffer wrote:
>> [...]
>
> I think Atila was talking about this one:
> struct A
> {
> 	~this() {}
> }
>
> void main()
> {
> 	auto a = A();
> 	shared b = A();
> }
>
> https://is.gd/kOYlWY

That's what I meant. I was on a train and only skimmed through.

Atila
July 18, 2017
On Tuesday, 18 July 2017 at 15:03:07 UTC, Kagamin wrote:
> On Tuesday, 18 July 2017 at 11:47:37 UTC, Petar Kirov [ZombineDev] wrote:
>> I think Atila was talking about this one:
>> struct A
>> {
>> 	~this() {}
>> }
>>
>> void main()
>> {
>> 	auto a = A();
>> 	shared b = A();
>> }
>
> This is strange. There's nothing that suggests that struct A and its destructor is thread-safe, yet compiler assumes it is.

Except for a programmer explicitly and manually calling the destructor (in which case, don't), the destructor is only ever called by one thread.

Atila
July 18, 2017
On Monday, 17 July 2017 at 19:30:53 UTC, Jack Stouffer wrote:
> On Monday, 17 July 2017 at 17:41:58 UTC, Atila Neves wrote:
>> On Monday, 17 July 2017 at 14:26:19 UTC, Jack Stouffer wrote:
>>> TL;DR: Issue 17658 [1] makes using shared very annoying/practically impossible.
>>>
>>> [...]
>>
>> I fixed this already, should be in the next release.
>>
>> Atila
>
> Are you sure? Because DMD nightly still errors:
>
> https://run.dlang.io?compiler=dmd-nightly&source=struct%20A%0A%7B%0A%20%20%20%20this(string%20a)%20%7B%7D%0A%20%20%20%20this(string%20a)%20shared%20%7B%7D%0A%0A%20%20%20%20~this()%20%7B%7D%0A%20%20%20%20~this()%20shared%20%7B%7D%0A%0A%20%20%20%20this(this)%20%7B%7D%0A%20%20%20%20this(this)%20shared%20%7B%7D%0A%7D%0A%0Avoid%20main()%0A%7B%0A%20%20%20%20shared%20f%20%3D%20A(%22%22)%3B%0A%7D
>
>
> (maybe we should remove the ban on URL shorteners for our own sites)

Now I've read your post properly: there is only one destructor. With the fix I mentioned, just don't defined the `shared` version, there's no need to. Postblit is still a problem, however.

Atila
July 18, 2017
On Tuesday, July 18, 2017 18:06:56 Atila Neves via Digitalmars-d wrote:
> On Tuesday, 18 July 2017 at 15:03:07 UTC, Kagamin wrote:
> > On Tuesday, 18 July 2017 at 11:47:37 UTC, Petar Kirov
> >
> > [ZombineDev] wrote:
> >> I think Atila was talking about this one:
> >> struct A
> >> {
> >>
> >>    ~this() {}
> >>
> >> }
> >>
> >> void main()
> >> {
> >>
> >>    auto a = A();
> >>    shared b = A();
> >>
> >> }
> >
> > This is strange. There's nothing that suggests that struct A and its destructor is thread-safe, yet compiler assumes it is.
>
> Except for a programmer explicitly and manually calling the destructor (in which case, don't), the destructor is only ever called by one thread.

It could still be a problem if the struct has a member variable that is a reference type, because then something else could refer to that object, and if it's shared, then you would need to protect it, and the operations that shared prevents should still be prevented. For full-on value types, it should be a non-issue though.

- Jonathan M Davis

« First   ‹ Prev
1 2 3 4 5