Re: [Vala] Locking null references




IMHO this shouldn't be allowed, just for the sake of consistency with
other platforms (i.e. Mono requires a non-null reference in null
statements).

And even if we don't consider consistency, let's discuss about the
technical aspects? In Mono a lock statement is translated to an API call
(Monitor.Enter()), how does it translate in vala? If it's similar, we
would be in a situation in which completely different parts of a running
program (let's say, library A and library B which are used by program C)
do concurrency blocks between each other if they end up using a null
object in a lock statement, which doesn't make much sense, right?

        Andres


El 30/03/10 03:30, Jim Nelson escribió:
In Vala, I can lock a null reference.  Is this by design or a side-effect?

class Xyzzy {
    private File file = null;

    public File get_file() {
        File f;
        lock (file) {
            if (file == null)
                file = File.new_for_path("/tmp");

            f = file;
        }

        return f;
    }
}

void main() {
    Xyzzy x = new Xyzzy();
    stdout.printf("%s\n", x.get_file().get_path());
    stdout.printf("%s\n", x.get_file().get_path());
    stdout.printf("%s\n", x.get_file().get_path());
}

I think this is fine and should be the documented behavior.  Because Vala
only allows locking member variables (and not "this"), being unable to lock
a nulled reference would require allocating a dummy object to lock against
or explicitly using a Mutex and forgoing lock().  I find both unappealing.

In other words, I think this is okay because it's locking access to the
reference and not locking the object itself.  This seems right to me -- but
I'd feel better if I knew this won't go away in the future.

-- Jim





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]