Re: [Vala] Singleton and reference count

[Jan Hudec <bulb ucw cz>]

On Thu, Apr 29, 2010 at 13:53:40 -0400, Sam Wilson wrote:
> On Thu, 2010-04-29 at 18:55 +0200, Jan Hudec wrote:
> > Hello,
> >
> > On Wed, April 28, 2010 13:46, Jan Niklas Hasse wrote:
> > > On Wed, Apr 28, 2010 at 11:31 AM, pancake <pancake youterm com> wrote:
> > > > On Apr 28, 2010, at 10:24 AM, Jan Niklas Hasse <jhasse gmail com> wrote:
> > >
> > > So shouldn't Vala unref namespace scoped variables when leaving their
> > > scope?
> >
> > IMHO there is no reason to do it. The compiler could do it (using the
> > atexit mechanism) but than there are many ways the process can terminate
> > without calling them anyway (calling _exit, receiving fatal signal, the power
> > going out etc.). Therefore the program shouldn't rely on them for anything
> > important anyway and since system will clean up resources anyway, they are
> > not needed for that either. So IMHO supporting them would just promote
> > unreliable code and is thus not worth doing.
>
> This is an important feature, and I don't see how it promotes unreliable
> code.

It is occasionally useful, but I don't really think it's important.

I worked on couple of applications already where the normal way of exiting
was reset of the device. Most applications for handheld and embedded devices
are like that. But during development on desktop, these applications do get
shut down "correctly", invoking destructors of all the singletons. Now
whenever somebody relies on that, it will seem to work in testing just to get
to production to fail there.

> In the event that the program terminates normally, libraries and

99.9% of libraries implemented in C never ever bother.

> globally defined objects should be destroyed properly. That way they can
> flush buffers,

For stdout it makes sense. But stderr is another matter (you do want that
after abnormal termination, so it needs to be line-buffered) and files need
to be closed explicitly anyway.

> or terminate network connections cleanly.

Either you need to send some closing command -- which you better do explcitly
and explicitly wait for reply and process it -- or you just need to close
them in which case you don't really need to bother, because the system will
do it equally well.

> Isn't that the
> point of the RAII pattern?

No. RAII is for things in dynamic scope to ensure the program does not leak
resources while running. It is extremely useful there and vala implements it
just fine. But you simply don't need to release resources when you are
exiting anyway.

> When a program is killed (or otherwise terminates abnormally) it is a
> special case, and needn't be handled by the compiler.

Well, it can't be. There is simply nothing that can be done if power goes
out. One instruction everything is fine and the next one never gets to
execute.

> I don't see a problem using atexit to implement this feature.

I don't see it either. Except it's nontrivial amount of work somebody has to
do, for which they'll need motivation and I personally don't see sufficient
benefit in it.

> IMHO vala should try and be as consistent as possible, and having to
> manually destroy global variables is not consistent with the rest of
> vala's memory management.

Being as consistent is possible is nice.

But for destroying the global objects, flushing stdout seems to be the only
reason I can seem to find. (Checking for memory leaks excluded, because GLib
won't free it's internal buffers anyway).

-- 
                                                 Jan 'Bulb' Hudec <bulb ucw cz>