Re: [Vala] Locking null references
- From: "Andrés G. Aragoneses" <knocte gmail com>
- To: vala-list gnome org
- Subject: Re: [Vala] Locking null references
- Date: Tue, 30 Mar 2010 11:47:05 +0200
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]