Subject: Re: [boost] re quest for interest in a garbage collection library
From: Vicente Botet Escriba (vicente.botet_at_[hidden])
Date: 2009-04-17 05:47:09
Achilleas Margaritis-4 wrote:
> Sid Sacek wrote:
>>>> It's the lack of a programming model that integrates
>>>> destructors and peoples' legitimate expectations that they will be
>>>> called to release non-memory resxources. What can you say about the
>>>> non-memory resources owned by a GC'd object that contains, say, a
>>> Personally, I don't see why resources like mutexes or files should be
>>> managed like memory. Resources like that are "binary" resources: they
>>> have two states (locked/unlocked, opened/closed), which is perfectly
>>> suited for RAII.
>> I think the question David was asking is; if a GC object is holding a
>> mutex that is currently holding a lock, then when does that lock
>> release, or how does that lock release? The GC may run in the future,
>> and in the meanwhile, that lock is frozen.
> Aren't scoped locks a better way to handle such issues? The big
> advantage of C++ is scoped construction/destruction.
> Unsubscribe & other changes:
The user can use already RAII on its application. Suppose that you have a
RAII class X that is garbage collected (inherits from gc_object<X>) that
holds a mutex (or a file handle) and lock (open) it on construction and
unlock (close) on destruction.
How the following behaves?
scoped_ptr<X> p(nex X());
When the unlock (close) function will be called?
Does it means that classes like X should not inherit from gc_object<X> and
the user of X must decide whether the new X() must be garbage collected or
What are the criteria X must satisfy to inherit from gc_object<X> without
The GC RAII combination rises clearly some issues, and the user must be
aware of them. The question is, what the GC library can provide to the user
to make user life easier and safer.
-- View this message in context: http://www.nabble.com/request-for-interest-in-a-garbage-collection-library-tp23028795p23094561.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk