On Wed, 2012-02-01 at 22:04 -0200, Rodrigo Kumpera wrote:
>
> I expect it to be exposed to further internal usage and which will
> better shape it.
>
I totally agree on this point. Maybe I could have some use on this via
p/invoke to itself (using __Internal). What do you think?
--
Regards,
Kon
2012/1/24 Konrad M.
>
>
> > Even if performance was backed in, it would not help a lot since you
> > have the large
> > bottleneck of file backed.
>
> As I said, I would rather not delete file directly on the callback's
> thread, but queue its deletion. Also the mentioned approach can be
> useful
On Mon, 2012-01-23 at 23:35 -0200, Rodrigo Kumpera wrote:
>
> There is no specially collector for finalizable objects. The finalizer
> will be called
> around the same time the callback for such an object would be.
I meant the sgen equivalent of the f-reachable queue. Callback will be
called aro
Hi all,
I think I was misunderstood. This is not beginner's question on how to
write classes with Disposable pattern (you mentioned) -- believe me, I
know that very well. Problem is rather as follows. Let's say we have an
object whose life is short - it is collected on first GC scan after
creation.
On 2012-01-24 02:32, Robert Vesse wrote:
If it is the case that you have unmanaged resources that you need to
clean up that you should really be using the IDisposable interface
and calling Dispose() on the class when you are done with it.
If it is possible for code paths to 'forget' to call Disp
If it is the case that you have unmanaged resources that you need to clean up
that you should really be using the IDisposable interface and calling Dispose()
on the class when you are done with it.
If it is possible for code paths to 'forget' to call Dispose() then you can
include a finalizer a
Thanks for the answer.
Here is the case:
Let's say I have a class which contains some data in temporary
file (for example some kind of cache which should not stay in memory).
I'd like to have this file removed when object of this class dies. I
can implement a finalizer but if I do this, object wi
We've thought about exporting such interface, but the maintenance burden
made us back off.
This interface has some short-coming and exposing it to managed code
has it's problems. For example, it doesn't support unregistering.
But, if you make your case on why such a feature would help you, I
can
Hi,
I've just noticed that runtime offers mono_gc_reference_queue_new
function, which can be used to register callback executed after
object is collected.
Is there a possibility of exporting this functionality to class library
to have it available from C# code? (Mono.Runtime or sth like that).
B
