Re: [Telepathy] Uniqueness of objects
Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Olli Salli Sent: Friday, October 03, 2008 1:12 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] Uniqueness of objects Some wizardry certainly needs to be performed even inside TelepathyQt4 to prevent using multiple Connection objects associated with the same remote connection - namely, not keeping the reference counter inside a single Connection object, but share it between Connections using a (bus uuid, remote conn service name) - refcounter mapping. Can you simply protect the constructor and create Connections only through the ConnectionManager? Best regards, Misha ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Uniqueness of objects
On Fri, Oct 3, 2008 at 1:31 PM, [EMAIL PROTECTED] wrote: Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Olli Salli Sent: Friday, October 03, 2008 1:12 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] Uniqueness of objects Some wizardry certainly needs to be performed even inside TelepathyQt4 to prevent using multiple Connection objects associated with the same remote connection - namely, not keeping the reference counter inside a single Connection object, but share it between Connections using a (bus uuid, remote conn service name) - refcounter mapping. Can you simply protect the constructor and create Connections only through the ConnectionManager? I'll look into this. Thanks for the suggestion. However, note that using ConnectionManager isn't the only way to get a Connection - you can get one eg. using MC to connect to an account or when handling a channel, etc. Some of these ways might be extensions not known to the library in advance, which might further complicate things. All of these ways to get the connection would then need to somehow relate to the API in the ConnectionManager to present the user with the Connection. Best regards, Misha Br, Olli Salli ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Uniqueness of objects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 03 Oct 2008 at 13:12:18 +0300, Olli Salli wrote: in fact, QDBus already does dbus_bus_get_private to get one instance of a DBusConnection for the session, system and starter buses, and shares that between all users of QDBusConnection::sessionBus() etc. Ah, brilliant. So telepathy-glib, telepathy-qt4 and telepathy-python can never end up sharing a DBusConnection, since dbus-glib is the only binding still using the shared connection :-) Some wizardry certainly needs to be performed even inside TelepathyQt4 to prevent using multiple Connection objects associated with the same remote connection - namely, not keeping the reference counter inside a single Connection object, but share it between Connections using a (bus uuid, remote conn service name) - refcounter mapping. Agreed. telepathy-glib will need to do this too (I'm working on code for that today). Simon -BEGIN PGP SIGNATURE- iD8DBQFI5gd9WSc8zVUw7HYRAkFlAKDgzdbasVbcz5tGCKs0AjtqBV2I9gCdGSbk 3xbxJa5fhTgPsXwo7ySLXII= =lhG+ -END PGP SIGNATURE- ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Uniqueness of objects
Ar 01/10/2008 am 14:55, ysgrifennodd Xavier Claessens: On mer, 2008-10-01 at 13:21 +0100, Simon McVittie wrote: On Wed, 01 Oct 2008 at 07:24:58 +0200, Xavier Claessens wrote: The spec doesn't say exactly what happens if ReleaseHandle is called more than once The spec does (or should) say that HoldHandle is idempotent, i.e. one call is equivalent to many calls. The intention and implementation is that whether a client :1.42 is holding handle 123 is binary - either it is or it isn't. So however many times :1.42 calls HoldHandle or RequestHandles, it only has one reference to handle 123, and ReleaseHandles([123]) is sufficient to release that reference. Sure, but what happens if I call ReleaseHandles 2 times? The first time the handle was Hold, so it's OK. The 2nd there is 2 possibilities: 1) The handle is already destroyed and I guess I get an error like invalid handle. 2) The handle is still hold by a channel or another process, in that case the spec is not clear, what happens? The CM silently ignore the call? An error is returned? You get an error because you don't hold a reference to that handle. What's the problem with doing reference counting on the client side, and mapping the 0-1 refs boundary to HoldHandles and the 1-0 refs boundary to ReleaseHandles? -- Dafydd ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Uniqueness of objects
Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Dafydd Harries Sent: Thursday, October 02, 2008 4:59 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] Uniqueness of objects What's the problem with doing reference counting on the client side, and mapping the 0-1 refs boundary to HoldHandles and the 1-0 refs boundary to ReleaseHandles? That's certainly possible. There's only the problem of two Telepathy client stacks in one process using the same DBus connection unbeknownst to each other. Which is considered a freak circus for purposes of this thread. Best regards, Misha ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Uniqueness of objects
Ar 02/10/2008 am 17:04, ysgrifennodd [EMAIL PROTECTED]: Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Dafydd Harries Sent: Thursday, October 02, 2008 4:59 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] Uniqueness of objects What's the problem with doing reference counting on the client side, and mapping the 0-1 refs boundary to HoldHandles and the 1-0 refs boundary to ReleaseHandles? That's certainly possible. There's only the problem of two Telepathy client stacks in one process using the same DBus connection unbeknownst to each other. Which is considered a freak circus for purposes of this thread. Surely the solution is not to use the same D-Bus connection. -- Dafydd ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Uniqueness of objects
Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Simon McVittie Sent: Tuesday, September 30, 2008 11:01 PM To: telepathy@lists.freedesktop.org Subject: [Telepathy] Uniqueness of objects Hmm... but thinking about it, even if we refcount handles in telepathy-glib, this doesn't help if telepathy-glib and telepathy-qt4 end up sharing a connection, since neither library will be willing to call into (= depend on) the other in order to update the shared handle cache :-( Any ideas? Don't do that, then? If any process happens to use two Telepathy client stacks at the same time, it's an architectural horror, isn't it? BR, Mikhail ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Uniqueness of objects
On Wed, 01 Oct 2008 at 07:24:58 +0200, Xavier Claessens wrote: The spec doesn't say exactly what happens if ReleaseHandle is called more than once The spec does (or should) say that HoldHandle is idempotent, i.e. one call is equivalent to many calls. The intention and implementation is that whether a client :1.42 is holding handle 123 is binary - either it is or it isn't. So however many times :1.42 calls HoldHandle or RequestHandles, it only has one reference to handle 123, and ReleaseHandles([123]) is sufficient to release that reference. Simon signature.asc Description: Digital signature ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Uniqueness of objects
On Wed, 01 Oct 2008 at 11:32:56 +0300, [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Simon McVittie [...] Hmm... but thinking about it, even if we refcount handles in telepathy-glib, this doesn't help if telepathy-glib and telepathy-qt4 end up sharing a connection, since neither library will be willing to call into (= depend on) the other in order to update the shared handle cache :-( Any ideas? Don't do that, then? If any process happens to use two Telepathy client stacks at the same time, it's an architectural horror, isn't it? It is. However, each stack can't necessarily know that the other exists, in the presence of a plugin architecture loading arbitrary misc into a process (pathological case: two Telepathy-enabling plugins are loaded into Firefox, one of which uses GLib and one of which uses Qt). The D-Bus library APIs, and the author of D-Bus, encourage even different stacks (GLib vs Qt vs raw libdbus) to share a DBusConnection (and hence a unique name). I believe dbus-glib and QDBus are in fact the only major bindings that do this connection sharing (dbus-python did once, but it turns out that preventing it from asserting basically requires it to have its own connection, so now it does). It might be reasonable for us to declare that we don't support this case - after all, we don't currently support using telepathy-glib from multiple threads either - but I can't see any way to enforce it. Simon signature.asc Description: Digital signature ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Uniqueness of objects
On mer, 2008-10-01 at 13:21 +0100, Simon McVittie wrote: On Wed, 01 Oct 2008 at 07:24:58 +0200, Xavier Claessens wrote: The spec doesn't say exactly what happens if ReleaseHandle is called more than once The spec does (or should) say that HoldHandle is idempotent, i.e. one call is equivalent to many calls. The intention and implementation is that whether a client :1.42 is holding handle 123 is binary - either it is or it isn't. So however many times :1.42 calls HoldHandle or RequestHandles, it only has one reference to handle 123, and ReleaseHandles([123]) is sufficient to release that reference. Sure, but what happens if I call ReleaseHandles 2 times? The first time the handle was Hold, so it's OK. The 2nd there is 2 possibilities: 1) The handle is already destroyed and I guess I get an error like invalid handle. 2) The handle is still hold by a channel or another process, in that case the spec is not clear, what happens? The CM silently ignore the call? An error is returned? Anyway, it's not really the debate here... Xavier. ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] Uniqueness of objects
I'm starting to wonder whether we need to *guarantee* that certain objects are unique, because of some reference-counting corners we've painted ourselves into. Handles are held per connection to the bus daemon, therefore we can never safely release any handles unless we can refcount them per (DBusConnection, Telepathy Connection) tuple. I think it's reasonable for us to forbid calling ReleaseHandles from user code without going via a Telepathy library, since that can't possibly work (unless the libraries *never* release handles, which seems undesirable). Accordingly, we should conceal ReleaseHandles from the telepathy-glib documentation. I don't think we can make TpConnection the object that has exactly one instance per (DBusConnection, Telepathy Connection), because TpConnection is subclassable. If you construct a TpConnection subclass MyConnection while a TpConnection exists for that (DBusConnection, TelepathyConnection) pair, that mustn't be a problem. So, we need some sort of handle-referencing helper (it needn't be visible to users, TpConnection could use it internally). Hmm... but thinking about it, even if we refcount handles in telepathy-glib, this doesn't help if telepathy-glib and telepathy-qt4 end up sharing a connection, since neither library will be willing to call into (= depend on) the other in order to update the shared handle cache :-( Any ideas? Simon signature.asc Description: Digital signature ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Uniqueness of objects
Hi, It's a bit late so I could be missing something, but what about that: 1) Change the meaning of HoldHandle to mean refcount++ 2) Change the meaning of ReleaseHandle to mean refcount-- 3) Each call that return a handle (RequestHandles, GetAllMembers, etc) make a refcount++ so the caller is responsible to call ReleaseHandle. 4) Handles spontaneously created and emitted in a signal have a weak ref that expires after X min if not reffed by HoldHandles (or GetMembers, etc). Where X is big enough for a dbus round-trip. Of course Telepathy libraries have to hide all that stuff from clients. Xavier Claessens. On mar, 2008-09-30 at 21:01 +0100, Simon McVittie wrote: I'm starting to wonder whether we need to *guarantee* that certain objects are unique, because of some reference-counting corners we've painted ourselves into. Handles are held per connection to the bus daemon, therefore we can never safely release any handles unless we can refcount them per (DBusConnection, Telepathy Connection) tuple. I think it's reasonable for us to forbid calling ReleaseHandles from user code without going via a Telepathy library, since that can't possibly work (unless the libraries *never* release handles, which seems undesirable). Accordingly, we should conceal ReleaseHandles from the telepathy-glib documentation. I don't think we can make TpConnection the object that has exactly one instance per (DBusConnection, Telepathy Connection), because TpConnection is subclassable. If you construct a TpConnection subclass MyConnection while a TpConnection exists for that (DBusConnection, TelepathyConnection) pair, that mustn't be a problem. So, we need some sort of handle-referencing helper (it needn't be visible to users, TpConnection could use it internally). Hmm... but thinking about it, even if we refcount handles in telepathy-glib, this doesn't help if telepathy-glib and telepathy-qt4 end up sharing a connection, since neither library will be willing to call into (= depend on) the other in order to update the shared handle cache :-( Any ideas? Simon ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Uniqueness of objects
On mar, 2008-09-30 at 22:04 +0100, Simon McVittie wrote: On Tue, 30 Sep 2008 at 22:42:16 +0200, Xavier Claessens wrote: It's a bit late so I could be missing something, but what about that: 1) Change the meaning of HoldHandle to mean refcount++ 2) Change the meaning of ReleaseHandle to mean refcount-- Yeah, I thought of that - distributed refcounting, basically (although we wouldn't allow clients to unref a handle more times than they'd reffed it, and we'd drop all their refs when they died like the current HoldHandle does - otherwise it'd be insane). This would mean current clients become leaky, although in practice current clients never release handles :-P We could deprecate those functions and add RefHandle/UnrefHandle. HoldHandle can still be implemented for compatibility by increasing the refcount only once if called many times. The spec doesn't say exactly what happens if ReleaseHandle is called more than once, so I guess we could just say ReleaseHandle==UnrefHandle. Like that it's perfectly OK to call HoldHandle 10 times, and then call UnrefHandle just once. Of course a process can't unref more than it reffed otherwise UnrefHandle returns an error. And if a process disappear all its refs are lost. I guess there is a race condition if the last UnrefHandle is received just before a RefHandle. Maybe we could wait X seconds before destroying an handle when refcount falls to 0, to let a chance to resurrect the handle... Or we just return an error in RefHandle Sorry, you are too late, the handle is already destroyed. In general the lifetime of a handle seen in a signal is tied to some fairly obvious object, usually a channel, which references the handles for as long as it exists. Right, so forget about 3 and 4, channels just keep one ref its handles. Xavier Claessens. ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
