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

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 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?

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

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.