• Sean Kelly (10/10) Sep 16 2005 The latest release of Ares is online and I've tried to make this one a b...
• James Dunne (34/49) Sep 18 2005 I would love it if Ares provided some mechanism to *guarantee*
• James Dunne (2/66) Sep 20 2005 No bites?
• Sean Kelly (8/50) Sep 20 2005 Sorry, I've had a lot going on recently :) I agree that it would be a n...
• James Dunne (12/70) Sep 20 2005 The problem is not quite so simple.

Sean Kelly <sean f4.ca> writes:

The latest release of Ares is online and I've tried to make this one a bit more
usable.  The filename has been changed to reflect the build number, the readme
has been expanded and an about file has been added.  For this version, the
Thread interface has been marginally finalized and some attempt has been made to
provide  methods that might be useful for debugging.  for those who don't know,
std.error provides a means to hook 'assert' so the process can be terminated or
a debugger can be signaled instead of merely throwing an exception.  As always,
comments and suggestions are very much appreciated.

http://www.dsource.org/projects/ares/


Sean

James Dunne <james.jdunne gmail.com> writes:

Sean Kelly wrote:
 The latest release of Ares is online and I've tried to make this one a bit more
 usable.  The filename has been changed to reflect the build number, the readme
 has been expanded and an about file has been added.  For this version, the
 Thread interface has been marginally finalized and some attempt has been made
to
 provide  methods that might be useful for debugging.  for those who don't know,
 std.error provides a means to hook 'assert' so the process can be terminated or
 a debugger can be signaled instead of merely throwing an exception.  As always,
 comments and suggestions are very much appreciated.
 
 http://www.dsource.org/projects/ares/
 
 
 Sean
 
 

I would love it if Ares provided some mechanism to *guarantee* 
destruction of objects on program termination, whether that termination 
be abnormal or normal (phobos currently does not do this).  This would 
come in handy for classes which manage more than memory resources, and 
which need some sort of guarantee of disposal on program termination.

I've put some thought into this myself and hacked up a Linux-only patch 
to phobos to try to implement this (not released, since it's Linux only 
at the moment):

I came up with a std module named 'std.disposable' which defines an 
interface called 'IDisposable' (I hope that doesn't conflict with COM 
interfaces...).  This interface defines nothing more than a void 
Dispose() method.

In order to have an object inheriting from the IDisposable interface be 
Dispose()'d on program termination, I wrote a function in the 
std.disposable module named 'void markForDisposal(IDisposable obj)'.  In 
the class's constructor (or an otherwise appropriate place), this 
function would be called to put the object's reference on the list of 
marked objects.  Similarly a function named 'void 
unmarkForDisposal(IDisposable obj)' would remove the object's reference 
from the list of marked objects.

In internal/dmain2.d, I modified it so that signals would be caught with 
a signal handler, which would in turn call a function that traverses the 
marked object list, calling Dispose() on each object.  The call per each 
object would be wrapped in a try .. catch block so as to "nearly 
guarantee" that all marked objects were attempted to be Dispose()'d.

I ran into a problem here (what I mean by 'nearly guarantee'), because I 
couldn't get it to where I could guarantee progress when a Dispose() 
method itself generates some nasty signal and would cause abnormal 
program termination.  This is akin to a signal handler generating a 
signal itself.  Admittedly, I didn't read too far into the Linux/POSIX 
signal specifications to find out how to correctly reset the signal 
handler from within the signal handler.

What do you think of getting this sort of functionality into Ares?

James Dunne <james.jdunne gmail.com> writes:

James Dunne wrote:
 Sean Kelly wrote:
 
 The latest release of Ares is online and I've tried to make this one a 
 bit more
 usable.  The filename has been changed to reflect the build number, 
 the readme
 has been expanded and an about file has been added.  For this version, 
 the
 Thread interface has been marginally finalized and some attempt has 
 been made to
 provide  methods that might be useful for debugging.  for those who 
 don't know,
 std.error provides a means to hook 'assert' so the process can be 
 terminated or
 a debugger can be signaled instead of merely throwing an exception.  
 As always,
 comments and suggestions are very much appreciated.

 http://www.dsource.org/projects/ares/


 Sean

 
 I would love it if Ares provided some mechanism to *guarantee* 
 destruction of objects on program termination, whether that termination 
 be abnormal or normal (phobos currently does not do this).  This would 
 come in handy for classes which manage more than memory resources, and 
 which need some sort of guarantee of disposal on program termination.
 
 I've put some thought into this myself and hacked up a Linux-only patch 
 to phobos to try to implement this (not released, since it's Linux only 
 at the moment):
 
 I came up with a std module named 'std.disposable' which defines an 
 interface called 'IDisposable' (I hope that doesn't conflict with COM 
 interfaces...).  This interface defines nothing more than a void 
 Dispose() method.
 
 In order to have an object inheriting from the IDisposable interface be 
 Dispose()'d on program termination, I wrote a function in the 
 std.disposable module named 'void markForDisposal(IDisposable obj)'.  In 
 the class's constructor (or an otherwise appropriate place), this 
 function would be called to put the object's reference on the list of 
 marked objects.  Similarly a function named 'void 
 unmarkForDisposal(IDisposable obj)' would remove the object's reference 
 from the list of marked objects.
 
 In internal/dmain2.d, I modified it so that signals would be caught with 
 a signal handler, which would in turn call a function that traverses the 
 marked object list, calling Dispose() on each object.  The call per each 
 object would be wrapped in a try .. catch block so as to "nearly 
 guarantee" that all marked objects were attempted to be Dispose()'d.
 
 I ran into a problem here (what I mean by 'nearly guarantee'), because I 
 couldn't get it to where I could guarantee progress when a Dispose() 
 method itself generates some nasty signal and would cause abnormal 
 program termination.  This is akin to a signal handler generating a 
 signal itself.  Admittedly, I didn't read too far into the Linux/POSIX 
 signal specifications to find out how to correctly reset the signal 
 handler from within the signal handler.
 
 What do you think of getting this sort of functionality into Ares?

No bites?

Sean Kelly <sean f4.ca> writes:

In article <dgpi4a$1ifq$1 digitaldaemon.com>, James Dunne says...
James Dunne wrote:
 
 I would love it if Ares provided some mechanism to *guarantee* 
 destruction of objects on program termination, whether that termination 
 be abnormal or normal (phobos currently does not do this).  This would 
 come in handy for classes which manage more than memory resources, and 
 which need some sort of guarantee of disposal on program termination.
 
 I've put some thought into this myself and hacked up a Linux-only patch 
 to phobos to try to implement this (not released, since it's Linux only 
 at the moment):
 
 I came up with a std module named 'std.disposable' which defines an 
 interface called 'IDisposable' (I hope that doesn't conflict with COM 
 interfaces...).  This interface defines nothing more than a void 
 Dispose() method.
 
 In order to have an object inheriting from the IDisposable interface be 
 Dispose()'d on program termination, I wrote a function in the 
 std.disposable module named 'void markForDisposal(IDisposable obj)'.  In 
 the class's constructor (or an otherwise appropriate place), this 
 function would be called to put the object's reference on the list of 
 marked objects.  Similarly a function named 'void 
 unmarkForDisposal(IDisposable obj)' would remove the object's reference 
 from the list of marked objects.
 
 In internal/dmain2.d, I modified it so that signals would be caught with 
 a signal handler, which would in turn call a function that traverses the 
 marked object list, calling Dispose() on each object.  The call per each 
 object would be wrapped in a try .. catch block so as to "nearly 
 guarantee" that all marked objects were attempted to be Dispose()'d.
 
 I ran into a problem here (what I mean by 'nearly guarantee'), because I 
 couldn't get it to where I could guarantee progress when a Dispose() 
 method itself generates some nasty signal and would cause abnormal 
 program termination.  This is akin to a signal handler generating a 
 signal itself.  Admittedly, I didn't read too far into the Linux/POSIX 
 signal specifications to find out how to correctly reset the signal 
 handler from within the signal handler.
 
 What do you think of getting this sort of functionality into Ares?

No bites?

Sorry, I've had a lot going on recently :)  I agree that it would be a nice
feature to have so I'll probably add it in some form before too terribly long.
It will likely either be done by adding a line to the cleanup code in
dmdrt.dmain2 or by building the feature into the GC (so it's run at the
beginning of gc_term).  Probably the latter, as the GC seems the appropriate
place for it.


Sean

James Dunne <james.jdunne gmail.com> writes:

Sean Kelly wrote:
 In article <dgpi4a$1ifq$1 digitaldaemon.com>, James Dunne says...
 
James Dunne wrote:

I would love it if Ares provided some mechanism to *guarantee* 
destruction of objects on program termination, whether that termination 
be abnormal or normal (phobos currently does not do this).  This would 
come in handy for classes which manage more than memory resources, and 
which need some sort of guarantee of disposal on program termination.

I've put some thought into this myself and hacked up a Linux-only patch 
to phobos to try to implement this (not released, since it's Linux only 
at the moment):

I came up with a std module named 'std.disposable' which defines an 
interface called 'IDisposable' (I hope that doesn't conflict with COM 
interfaces...).  This interface defines nothing more than a void 
Dispose() method.

In order to have an object inheriting from the IDisposable interface be 
Dispose()'d on program termination, I wrote a function in the 
std.disposable module named 'void markForDisposal(IDisposable obj)'.  In 
the class's constructor (or an otherwise appropriate place), this 
function would be called to put the object's reference on the list of 
marked objects.  Similarly a function named 'void 
unmarkForDisposal(IDisposable obj)' would remove the object's reference 
from the list of marked objects.

In internal/dmain2.d, I modified it so that signals would be caught with 
a signal handler, which would in turn call a function that traverses the 
marked object list, calling Dispose() on each object.  The call per each 
object would be wrapped in a try .. catch block so as to "nearly 
guarantee" that all marked objects were attempted to be Dispose()'d.

I ran into a problem here (what I mean by 'nearly guarantee'), because I 
couldn't get it to where I could guarantee progress when a Dispose() 
method itself generates some nasty signal and would cause abnormal 
program termination.  This is akin to a signal handler generating a 
signal itself.  Admittedly, I didn't read too far into the Linux/POSIX 
signal specifications to find out how to correctly reset the signal 
handler from within the signal handler.

What do you think of getting this sort of functionality into Ares?

No bites?

 
 
 Sorry, I've had a lot going on recently :)  I agree that it would be a nice
 feature to have so I'll probably add it in some form before too terribly long.
 It will likely either be done by adding a line to the cleanup code in
 dmdrt.dmain2 or by building the feature into the GC (so it's run at the
 beginning of gc_term).  Probably the latter, as the GC seems the appropriate
 place for it.
 
 
 Sean
 
 

The problem is not quite so simple.

I'm not sure if you're aware, but gc_term() is not called when the 
program abnormally terminates.  This is the problem with using 
destructors for resource-management; not to mention that any referenced 
data within a destructor is to be assumed invalid.  This is why there 
should be a Dispose() method, to be called before the destructor.  In 
fact, it could be completely independent of the constructor/destructor.

In order to trap on abnormal program termination, you must hook some 
signal handlers or event trappers, whatever the case may be, before 
running the user's D main() function.

Thanks for your reply, however!  I hope you find time for it.