May 20, 2015
On Wednesday, 20 May 2015 at 13:54:29 UTC, bitwise wrote:
> Yes, but D claims to support manual memory management. It seems to get second class treatment though.

It's WIP. There were thoughts to run finalizers on the thread where the object was allocated (I doubt it's a good idea, though). Anyway, if you're doing manual memory management, how GC popped up? If you have your manual memory managed with GC, it means you have a memory leak: manually managed memory shouldn't become garbage without being freed. I suppose it will be a long way before D rediscovers .net practices.

> I'm pretty sure I can PInvoke malloc in C# too ;)

I use Marshal.AllocHGlobal.

>>> Basically, I can't design a struct and be sure the destructor will be called on the same thread as where it went out of scope.
>>
>> If your resource finalization code has some specific threading requirements, you implement those yourself in a way your code requires it. Or instead freeing resources normally in due time.
>
>  AFAIK D does not provide any built in functionality like Objective-C's 'runOnMainThread', which makes this a painful option.

You asked for destructor being called on the thread where it went out of scope, which is not necessarily the main thread.
May 21, 2015
On 5/19/15 7:03 PM, bitwise wrote:
> On Tue, 19 May 2015 18:47:26 -0400, Steven Schveighoffer
> <schveiguy@yahoo.com> wrote:
>
>> On 5/19/15 5:07 PM, bitwise wrote:
>>> On Tue, 19 May 2015 15:36:21 -0400, rsw0x <anonymous@anonymous.com>
>>> wrote:
>>>
>>>> On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
>>>>> On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
>>>>> <destructionator@gmail.com> wrote:
>>>>>
>>>>>> On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
>>>>>>> Is this also true for D?
>>>>>>
>>>>>> Yes. The GC considers all the unreferenced memory dead at the same
>>>>>> time and may clean up the class and its members in any order.
>>>>>
>>>>> Ugh... I was really hoping D had something better up it's sleeve.
>>>>
>>>> It actually does, check out RefCounted!T and Unique!T in std.typecons.
>>>> They're sort of limited right now but undergoing a major revamp in
>>>> 2.068.
>>>
>>> Any idea what the plans are?. Does RefCounted become thread safe?
>>>
>>> Correct me if I'm wrong though, but even if RefCounted itself was
>>> thread-safe, RefCounted objects could still be placed in classes, at
>>> which point you might as well use a GC'ed class instead, because you'd
>>> be back to square-one with your destructor racing around on some random
>>> thread.
>>
>> With the current GC, yes. RefCounted needs to be thread safe in order
>> to use it. But if we change the GC, we could ensure destructors are
>> only called in the thread they were created in (simply defer
>> destructors until the next GC call in that thread).
>
> This seems like it could result in some destructors being delayed
> indefinitely.

That's already the case.

>>> I'm finding it hard to be optimistic about the memory model of D.
>>>
>>> The idea of marking absolutely everything in your program with "@nogc"
>>> just to make it safe is ludicrous.
>>
>> That makes no sense, the GC is not unsafe.
>>
>
> Maybe I worded that incorrectly, but my point is that when you're
> running with the GC disabled, you should only use methods marked with
> @nogc if you want to make sure your code doesn't leak right? that's a
> lot of attributes O_O

OK, I see your point. Yes, you need @nogc to not leak.

The point of @nogc was to ensure machine-checkable prevention of GC calls. The idea is to put @nogc on main(), and then all your calls will have to be @nogc. Where it absolutely comes in handy is compiler generated GC calls that can be unexpected (e.g. closures). But I'd still recommend not disabling the GC, as that is redundant, and having a stray GC call will not leak if something somehow (roguely) uses the GC (there are ways to do this). Alternatively, you can run a collection at opportune times just in case.

It means you have to live with a subset of the language, and phobos cannot support you 100%. We are working to ensure that it's @nogc as much as possible.

-Steve
May 21, 2015
On 5/20/15 11:09 AM, Kagamin wrote:
> On Wednesday, 20 May 2015 at 13:54:29 UTC, bitwise wrote:
>> Yes, but D claims to support manual memory management. It seems to get
>> second class treatment though.
>
> It's WIP. There were thoughts to run finalizers on the thread where the
> object was allocated (I doubt it's a good idea, though).

It's essential for lockless thread-local programming.

At this moment, a thread-local-only heap pointer must deal with multi-threading issues simply because destructors can run on another thread, even though the reference is thread-local. The biggest example right now is reference-counted structures such as std.stdio.File.

The absolute best part about the shared qualifier is the lack of shared qualifier -- you can be certain something isn't shared if it doesn't have shared attached to it. Right now, even in that case, you still have to worry about RAII objects being destroyed in other threads. We shouldn't have to worry about that.

-Steve
May 21, 2015
On Thursday, 21 May 2015 at 12:33:33 UTC, Steven Schveighoffer wrote:
> At this moment, a thread-local-only heap pointer must deal with multi-threading issues simply because destructors can run on another thread, even though the reference is thread-local. The biggest example right now is reference-counted structures such as std.stdio.File.

You mean the reference counting part?
May 21, 2015
On Thursday, 21 May 2015 at 12:33:33 UTC, Steven Schveighoffer wrote:
> At this moment, a thread-local-only heap pointer must deal with multi-threading issues simply because destructors can run on another thread, even though the reference is thread-local. The biggest example right now is reference-counted structures such as std.stdio.File.

Just for the record: .net doesn't use reference counting for system resources like files, it works fine, such resources usually have well-defined ownership.
May 21, 2015
On 5/21/15 8:40 AM, Kagamin wrote:
> On Thursday, 21 May 2015 at 12:33:33 UTC, Steven Schveighoffer wrote:
>> At this moment, a thread-local-only heap pointer must deal with
>> multi-threading issues simply because destructors can run on another
>> thread, even though the reference is thread-local. The biggest example
>> right now is reference-counted structures such as std.stdio.File.
>
> You mean the reference counting part?

Yes, if you put a File as a class member, the destructor of the class would call the File's destructor, which could be run in any thread. Since File is a reference counted wrapper, the destructor decrements the reference count and possibly closes the file. The whole operation must be atomic if we are spread across threads.

But if you only ever access that containing class in a local thread, you are paying the cost of locking (or at least atomic decrement) for all reference counts on that file, for very little reason. Especially if the File doesn't live in a heap object (dtor doesn't know where it's being called from).

-Steve
1 2 3
Next ›   Last »