www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Ares 0.1

reply 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
Sep 16 2005
parent reply 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?
Sep 18 2005
parent reply 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?
Sep 20 2005
parent reply 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
Sep 20 2005
parent 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.
Sep 20 2005