There is another alternative I used for my project. I had needed to use a REAL GObject singleton in my code, so I write some code in C that do this perfectly. Now this singleton could be "non-leaked", which means that when there's no refs to it, it destroy itself.
The tricky thing was to do this thread-safety, i.e. beware from situation when user request a new instance exactly while other thread release the last reference to the previous instance. I have come up with solution using the method: g_object_add_toggle_ref which is thread safe. When the callback is invoked, I use my "locks" to transmit that the object is not longer vialed to be used anymore, and need to create a new one. Here is singleton.c: http://sourceforge.net/p/maxdream/maxdream/ci/efa2d719f2066970d0336969e0b8469488e1feb4/tree/src/maxdream-kernel/utils/singleton.c I sent you this alternative since I think you might afraid of thread local list performance :-) Not the simplest solution, but works well. Tal > From: [email protected] > To: [email protected] > Date: Sat, 21 Dec 2013 14:45:54 +0800 > Subject: Re: [Vala] "vala friendly" atomic pointer > > Thank you for the clarification and the link > on HazardPointer. > > > Nice day > Nor Jaidi Tuah > > > > > > > PRIVILEGED/CONFIDENTIAL information may be contained in this message. If you > are neither the addressee (intended recipient) nor an authorised recipient of > the addressee, and have received this message in error, please destroy this > message (including attachments) and notify the sender immediately. STRICT > PROHIBITION: This message, whether in part or in whole, should not be > reviewed, retained, copied, reused, disclosed, distributed or used for any > purpose whatsoever. Such unauthorised use may be unlawful and may contain > material protected by the Official Secrets Act (Cap 153) of the Laws of > Brunei Darussalam. DISCLAIMER: We/This Department/The Government of Brunei > Darussalam, accept[s] no responsibility for loss or damage arising from the > use of this message in any manner whatsoever. Our messages are checked for > viruses but we do not accept liability for any viruses which may be > transmitted in or with this message. > _______________________________________________ > vala-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/vala-list _______________________________________________ vala-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/vala-list
