Re: [Vala] "vala friendly" atomic pointer

[Tal Hadad <tal_hd hotmail com>]

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: norjaidi tuah ubd edu bn
> To: vala-list gnome org
> 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
> vala-list gnome org
> https://mail.gnome.org/mailman/listinfo/vala-list