gmane.comp.lang.d.general

Re: Live code analysis in DCT

Bernard Helyer — 2012-05-24T16:29:03

Just sent you an email saying I'm willing to change SDC's license 
to Boost.

Re: Destructor nonsense on dlang.org

David Nadlinger — 2012-05-24T16:17:15

On Thursday, 24 May 2012 at 16:06:23 UTC, Andrei Alexandrescu 
wrote:

You can't do that in today's D either, going by the spec as well 
by the actual implementation.

David

Re: Destructor nonsense on dlang.org

Alex Rønne Petersen — 2012-05-24T16:12:36

Finalization happens once the world has been resumed, meaning GC 
allocation (and even explicit deallocation) should be perfectly safe. 
This is absolutely essential: Finalization models where finalizers run 
in a paused world are doomed to fail miserably.

Re: Destructor nonsense on dlang.org

Andrei Alexandrescu — 2012-05-24T16:10:39

This is possible but not trivial as the state of zombie objects must be 
properly defined. Often such objects will fail their invariant (a 
reasonable state of a zombie object is with the correct vtable, no 
mutex, and all fields in the pre-constructor state).


As one aspect, calls to new should fail during destruction.


Andrei

Re: Destructor nonsense on dlang.org

Alex Rønne Petersen — 2012-05-24T16:10:31

No, the docs specifically state that this is invalid (and it currently 
throws InvalidMemoryOperationError in most cases).

Whether it *should* be allowed is arguable, but it isn't currently, both 
in docs and impl.

Re: Destructor nonsense on dlang.org

Andrei Alexandrescu — 2012-05-24T16:06:24

It does matter because a destructor may use an object that has just been 
destroyed.

Andrei

Re: Destructor nonsense on dlang.org

Tove — 2012-05-24T16:02:29

On Thursday, 24 May 2012 at 15:43:57 UTC, Alex Rønne Petersen 
wrote:

Hmm... well, as long as it's optional behavior... as in my case I 
actually want to go in the opposite direction... short-lived tool 
which claims x resources and is run once for every file...

So in this case, resources should be "free:ed" _unless_ it's at 
program termination... as then it just slows down the shutdown 
procedure, the OS reclaim it faster anyway.

Re: Destructor nonsense on dlang.org

Alex Rønne Petersen — 2012-05-24T15:43:55

So does .NET. It just does it with some trampoline magic. Non-D code 
just has to call thread_attachThis()/thread_detachThis() and friends.


The CLR waits for all threads to have shut down (including daemon 
threads). That's not equal to all static/__gshared data being nulled 
out, mind you. All data is cleared out once all threads, including the 
finalizer thread, have been terminated one way or another.

And yes, it is thread safe.


Don't need a virtual machine. We already have the infrastructure to do 
it in druntime, we just need to make the lifetime and GC code respect 
the C#/CLR finalization semantics if we want to go with those.


No, but a sane implementation made for a sane spec should. ;)


We just need a dispose pattern whereby explicit dispose() instructs the 
GC to not finalize.


None. I just came across it in the docs and found it completely insane.

Re: Destructor nonsense on dlang.org

deadalnix — 2012-05-24T15:27:48

Le 24/05/2012 16:54, Andrei Alexandrescu a écrit :

So what ?

Each GC passes must, mark object that have to be removed, call finalizer 
on them all, THEN recycle memory.

So « zombie » object can still refer to one another in finalization.

The real problem is resurrection, which should be 100% forbiden and this 
must be enforced by the language (ie, the scopeness of this parameter is 
something important).

Re: Destructor nonsense on dlang.org

deadalnix — 2012-05-24T15:21:09

Le 24/05/2012 15:49, Steven Schveighoffer a écrit :

Indeed. But java's way of doing it is very poor.

Re: Destructor nonsense on dlang.org

Michel Fortin — 2012-05-24T15:18:01

On 2012-05-24 14:35:45 +0000, Alex Rønne Petersen <alex< at >lycus.org> said:


.NET is a virtual machine which has total control of all the code that 
runs. D has to work with the C runtime and other non-D code that might 
use D code more or less directly.

The interesting question is *how* do they do it without causing 
thread-safety issues? Perhaps they wait until all threads have been 
terminated, or perhaps they're unsafe too. Would doing the same be 
appropriate for D? Does this mean we can't use anything using static 
and global variables in destructors because they might have been 
finalized? If so, how does the compiler detects this?

If there's a way and it is not overly costly in performance, it might 
be a good idea. But we're not in a virtual machine, there are more 
constrains we must abide to and we might have to make different 
compromises.

Enlarging the scope of all this, there is already some impending 
problems with how destructors are handled in D that can easily create 
low-level races. And this applies to struct destructors too, when the 
struct is put on the heap or is a member of an object. We're in the 
need of a global solution for all this.

<http://d.puremagic.com/issues/show_bug.cgi?id=4621>
<http://d.puremagic.com/issues/show_bug.cgi?id=4624>



Well, not according to the current spec.

It could make sense to do so, although I'm not sure. Freeing "external" 
resources can mean many things: if we're talking about externally 
allocated memory, open files, sockets, mutexes, etc., there's no need 
to finalize that at the end of the program: the OS will do the cleanup 
for us. If we're talking about advisory locks on files, then there's 
definitely a need to clear the lock, although I'm not sure it makes 
sense to make the release dependent on a non-deterministic GC.

So I'm curious, what resource are we trying to free here?

Re: Destructor nonsense on dlang.org

David Nadlinger — 2012-05-24T15:17:56

As for replicating that functionality, Scoped!T could always 
check for a magic dispose() method (maybe with another name, a 
marker parameter, …) and if it exists, call it on destruction.

But of course, the »universality« of the Tango runtimes 
solution is lost with this.

David

Re: Destructor nonsense on dlang.org

Steven Schveighoffer — 2012-05-24T15:17:04


We can easily hook that in object.clear, which any scoped library  
implementation should be calling.

-Steve

Re: Destructor nonsense on dlang.org

Jacob Carlborg — 2012-05-24T15:04:06


Object.dispose in Tango is called on scope exit if the object is 
variable is declared "scope". "scope" is deprecated in D2.

Re: Destructor nonsense on dlang.org

Andrei Alexandrescu — 2012-05-24T14:54:11

They may refer to one another.

Andrei

Re: Destructor nonsense on dlang.org

Alex Rønne Petersen — 2012-05-24T14:57:26

Doesn't matter: Nothing is guaranteed about order of finalization (and 
this is reasonable). Thus, the finalizers can be run in any arbitrary 
order. The important point here is that they are run *at all*.

Re: Destructor nonsense on dlang.org

Steven Schveighoffer — 2012-05-24T14:53:58

On Thu, 24 May 2012 10:30:02 -0400, Alex Rønne Petersen <alex< at >lycus.org>  
wrote:


I only found one definition for finalizer on wikipedia, and it fits D's  
definition.

What I think we need is a dispose pattern for objects, like Tango has.

-Steve

Re: Destructor nonsense on dlang.org

Alex Rønne Petersen — 2012-05-24T14:56:31

Just look at /usr/include/gc/gc.h (from libgc, the Boehm-Demers-Weiser 
GC). It has 3 (if not 4) different kinds of finalization. To be 
specific, the finalization I believe we need is the *_no_order behavior. 
This is the behavior C# and the CLR follow.

Re: dget - getting code from github

David Nadlinger — 2012-05-24T14:43:39

Oh, and maybe I'm a bit to pessimistic on that, but a project 
that takes »only one or two days« and »doesn't require much of 
any design« probably won't offer much functionality over 
»git/hg/<xyz> clone <url>«, and thus is likely to rather be a 
needless complication than much of a timesaver.

With dget in place, you either still need to go to the respective 
hosting site to find out that the project even exists, or we need 
a central list of available libraries, in which case we are 
already halfway towards a package manager. Now add versioning, a 
very ubiquitous concern, into the mix…

By the way, if you really just need to fetch the latest source 
tree for a GitHub project, you don't even need a local Git 
client. Just click the big »ZIP« button (taking you e.g. to 
https://github.com/D-Programming-Language/phobos/zipball/master) 
– works for branches and tags as well.

David

Re: Destructor nonsense on dlang.org

Alex Rønne Petersen — 2012-05-24T14:35:45

That's silly. Microsoft .NET and Mono have been running finalizers on 
runtime shutdown for a long time without problems.


Right, but I think if we guarantee finalization at shutdown, that 
shouldn't matter.


Even such an implementation should free all memory at shutdown, and, at 
that point, run finalizers.

Re: Destructor nonsense on dlang.org

Alex Rønne Petersen — 2012-05-24T14:38:10

We should really expose a waitForFinalizers() function in core.memory.