[M3devel] WeakRef.T does not clean all WeakRefs on prorgam exit

Jay K jay.krell at cornell.edu
Fri May 29 22:49:30 CEST 2015


Imho you should take this approach:

If you are only managing memory and file handles and socket handles,
or Win32 kernel handles (events/mutexes/semaphores/registry keys),
you should just rely on the kernel cleaning everything up when the process dies.

Doing everything peacemeal is just a waste of time.

Imagine that there is a null deref and you abruptly go away.That shouldn't/doesn't leak either.And attempting to cleanup in this path is dangerous.



In fact, any resource that you want to guaranteeably be cleaned up,
should be backed by the kernel.


If you are talking over the network to something, and you abruptly exit,
that network server will eventually notice a timeout and clean up anything
it has allocated on your behalf.

Now, on the other hand, if your .dll is gracefull unloaded and the processis still running, that is another matter, and one I suspect we don't handle.I'm not sure we really handle .dll/.sos in Modula-3 w/o the main executable being Modula-3.That could use repair.On Windows it is a matter of writing DllMain in m3core.Likely something similar on the other systems. Heck, maybe just a C++ static with a constructor and destructor.That is kinda the portable interface to DllMain(process attach) and whatever are the Unix analogs.Seriously. Just as we have main optionally in C.

Agreed?

Thread notifications would also be nice. This is an area that hasn't evolved as well as process notification.
  - Jay




> Date: Fri, 29 May 2015 21:13:38 +0200
> From: estellnb at elstel.org
> To: m3devel at elegosoft.com
> Subject: [M3devel] WeakRef.T does not clean all WeakRefs on prorgam exit
> 
>    Today I was writing an object oriented interface to some external 
> library.
> As every object holds at least a reference to an embedded C-heap object I
> wanted to make use of WeakRefs to get an automatic cleanup for the
> embedded C-heap objects. However I had to notice that no cleanup occurs
> and that the reference can still be reconstructed from the WeakRef even
> after assigning NULL and running the garbage collector by calling two times
> RTCollectorSRC.StartCollection & FinishCollection in sequence. I have
> further tried to disable incremental and generational collection and to set
> the gcRatio to 100.0 as well as moving the RefAny into a subprocedure
> but all of it did not help either. There is only one Refany in my program
> and thus no cyclic dependency.
>    Does anyone have a suggestion on how I could make the automatic
> cleanup work ready for testing it (appart from calling the cleanup proc
> directly)?
>    From the past I  know the WeakRef implementation of PM3 to some extent:
> there was no special cleanup on program exit. I believe on program exit
> all WeakRefs should be freed in order to let the operating system reclaim
> all resources. Under Linux that should work automatically though some
> resources like sockets may last long until they become available again.
> Other OSes like the eComstation can not reclaim all resources when it
> comes f.i. to shared memory.
>    Anyone here who believes that special cleanup for WeakRefs should be
> done on program exit?
> 
>    ... and one more question about how to handle WeakRefs?
> Do I need to keep the WeakRef-record after installing the cleanup proc
> with WeakRef.FromRef(...)? - or may I simply discard it while the cleanup
> should still be done without it?
> 
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150529/148869db/attachment-0002.html>


More information about the M3devel mailing list