Hi all,
Attached you can find my proposal for signal disconnect support,
that seems needed in some cases. Note that the code is purely
experimental and not tested at all. It's just for discussion.
The implementation details follow.
First, just remember you we had a handlers list in glib.Object, list
that was needed so the last strong ref to a handler is stored java side,
not JNI side, so GC could detect reference cycles.
So, I have modified that list, in order to store not just a reference to
the handler, but also the signal name, and the opaque handlerId we get
form glib when the signal is connected. This info is stored in a new
package-visible class SignalHandlerInfo.
So, when user connects to a signal, we store that reference in the
Object. This way, we can later retrieve the handler id and disconnect
it. Moreover, before connecting to the signal, we check if the handler
is not already connected. If it is, I just return without connecting it
again (we may want to change this later...).
Internally, SignalHandlerInfo are stored in an unsorted LinkedList, not
a map. It might seem ugly (we need to transverse the list during
searches), but it has less memory pressure than a HashMap, and the look
up penalty do not actually happen as: a) the number of handlers tend to
be small (few handlers per object), so a list is fast enough, and b) you
usually do not continuously connect/disconnect from signals.
Finally, notice that the key method is Plumbing.disconnectSignal(Object,
Signal,String), that allows you to disconnect a handler from a given
signal, by signal name.
Cheers
Vreixo
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com |
