Re: GObjectClass.dispose and bringing objects back to life

[Tristan Van Berkom <tvb gnome org>]

2011/12/5 David Nečas <yeti physics muni cz>:
> On Sun, Dec 04, 2011 at 01:40:58PM +0000, Emmanuele Bassi wrote:
>>
>> this is, of course, not true: GNOME is full of badly written GObject
>> code, mostly because it has been written at various stages of the
>> learning process of various people. plus, the documentation is not
>> entirely clear in a lot of places, thus the learning process can (and
>> effectively is) broken.
>> ...
>>
>> objects should obviously not be in a fully functional state after
>> dispose - but they should be in a stable state, so that other objects
>> referencing them from outside of the boundaries of their code space
>> can still hold a valid reference to them, until such time that every
>> reference can be released.
>
> So, who thinks this idea is not actually inherently inconsistent please
> please specify in the documentation, based on your rationale, how are
> objects supposed to behave in the disposed state.  Namely with respect
> to (not) keeping impossible invariants, returning nontrivial
> no-longer-available values, methods that normally create or acquire
> something before returning it and other practical issues.  Or say that
> there can be certain things the object owners may not do with disposed
> objects.  Or anything.  This
>
>     The object is also expected to be able to answer client method
>     invocations (with possibly an error code but no memory violation)
>     until finalize is executed.
>
> has as, a practical guide, approximately the same value as ‘people
> should live together in peace’.

It's a gray area that has not needed real clarification with real-world
code thus far, and I doubt it really absolutely needs clarification.

'Let us live in peace' is actually pretty much the gist of it afaics.

Why is this a non-issue ?

Because during the dispose cycle of objects, sane people don't
call apis which would ever fail at dispose time.

People might however call functions/macros like:
 - g_object_get_qdata(), i.e. I have some explicitly attached data I
want to inspect once while disposing,
                                             and for whatever reason I
chose not to call g_object_set_data_full()
 - g_type_name_from_instance() (i.e., sometimes I like to print the type
                                                      names and
reference counts of object
                                                      hierarchies
being destroyed, just to debug my own code)

Probably much existing code will fire run-time assertions when asked
to actually
perform a task at dispose time after an important resource is already discarded.

I think the policy right now, and has always been, "don't crash because your api
has been accessed at dispose time".

Do we need a more explicit policy ? Do we need to define what code should do
when asked to do something useful after dispose time ?

Considering that any sane code does not ever ask an object to do anything
useful after dispose time, no... it would just be an exercise of
planning for what
to do in code that is anyway, not meant to be reached.

That said, policy about locking and sharing of objects in MT environments
(related more to GIO than pure GObject) _might_ need clarification.

Implementing MT-safe singleton objects (as was I think the case in the referred
bug report) is probably just damn complex to do, definitely needs to be done
with some manual locking around the access to the singleton static pointer
and probably just a really bad idea to use in conjunction with GObject weak
references.

That is anyway, IMO, a separate discussion than the one we are having
about policy at dispose time.

Cheers,
          -Tristan