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
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Locking null references
Hi Jim, On Mon, 2010-03-29 at 18:30 -0700, Jim Nelson wrote: In Vala, I can lock a null reference. Is this by design or a side-effect? It's by design (constrained by GObject). Unlike in C#/.NET, we don't have a monitor available in every object. Due to this constraint, we've decided to use different lock statement semantics compared to C#. The only other option would have been to not support lock statements at all . In Vala lock(foo) locks the field `foo' and not the instance where `foo` points to. This means that the current value of the field is completely irrelevant, and locking a field whose value happens to be null is perfectly fine. 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. Yes, it's unfortunate that we can't properly support lock(this) as GObject doesn't support it and we can't just add a mutex field to instance structs as this would result in issues when using lock(this) in subclasses. Otherwise, I'd probably recommend using lock(this) in most cases. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Locking null references
Hi Jürg: El 30/03/10 11:35, Jürg Billeter escribió: Hi Jim, On Mon, 2010-03-29 at 18:30 -0700, Jim Nelson wrote: In Vala, I can lock a null reference. Is this by design or a side-effect? It's by design (constrained by GObject). Unlike in C#/.NET, we don't have a monitor available in every object. Due to this constraint, we've AFAIK, it's not that there's a Monitor available in every object. The lock statement is translated into a Monitor.Enter() call, but note that this is a static function call. decided to use different lock statement semantics compared to C#. The only other option would have been to not support lock statements at all . Well, I'm wondering about a 3rd option which would be a compromise: that vala translate every lock statement with a minimal null-check first, so if the condition is not met, an exception is raised? What do you think about this approach? In Vala lock(foo) locks the field `foo' and not the instance where `foo` points to. This means that the current value of the field is completely irrelevant, and locking a field whose value happens to be null is perfectly fine. 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. Yes, it's unfortunate that we can't properly support lock(this) as GObject doesn't support it and we can't just add a mutex field to instance structs as this would result in issues when using lock(this) in subclasses. Otherwise, I'd probably recommend using lock(this) in most cases. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Locking null references
Hi Andrés, On Tue, 2010-03-30 at 11:47 +0200, Andrés G. Aragoneses wrote: El 30/03/10 11:35, Jürg Billeter escribió: On Mon, 2010-03-29 at 18:30 -0700, Jim Nelson wrote: In Vala, I can lock a null reference. Is this by design or a side-effect? It's by design (constrained by GObject). Unlike in C#/.NET, we don't have a monitor available in every object. Due to this constraint, we've AFAIK, it's not that there's a Monitor available in every object. The lock statement is translated into a Monitor.Enter() call, but note that this is a static function call. The runtime uses a per instance field to implement Monitor.Enter, as far as I know. decided to use different lock statement semantics compared to C#. The only other option would have been to not support lock statements at all . Well, I'm wondering about a 3rd option which would be a compromise: that vala translate every lock statement with a minimal null-check first, so if the condition is not met, an exception is raised? What do you think about this approach? I fail to see what we would gain by doing that. The semantics would still differ significantly from C#. I don't see a reason why the field value should ever be relevant with Vala's lock statement semantics. For example, you can also lock integer fields where the null check wouldn't make any sense. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
