RES: mutex doubt

[Marcelo Elias Del Valle - SYSMAP SOLUTIONS - Claro MA-SP - <Marcelo Valle claro com br>]

Hello,

        Just for the Record: I don't know why, but although the problem I described bellow happens for static 
mutexes, it didn't happended for dynamic ones. My problem is solved, one my app requires thread to run.
        About the core dump happening when I called g_file_new_for_path(), when I started calling 
g_thread_init() before g_type_init() it stopped happening. It was hard for me to associate a gio problem with 
the threads, but I think this won't happen in newer versions, as g_thread_init is auto called. Anyway, hope 
the feedback helps.
        Thanks for the answers. Guess I am starting to know glib a bit better. :D

Regards,
Marcelo.

-----Mensagem original-----
De: gtk-app-devel-list-bounces gnome org [mailto:gtk-app-devel-list-bounces gnome org] Em nome de Marcelo 
Elias Del Valle - SYSMAP SOLUTIONS - Claro MA-SP -
Enviada em: quarta-feira, 7 de dezembro de 2011 14:36
Para: Tristan Van Berkom; jcupitt gmail com
Cc: gtk-app-devel-list gnome org
Assunto: RES: mutex doubt

Hello,

-----Mensagem original-----
De: tristan van berkom gmail com [mailto:tristan van berkom gmail com] Em nome de Tristan Van Berkom
Assunto: Re: mutex doubt


> Out of curiosity, what is "glib startup" ?
> Do you mean as a part of g_type_init() ?

        Yes, exactly

> Or, can glib programs which don't make use of GObject use
> threads at all ? Must _those_ programs still call g_thread_init()
> before using threads ?

        I wasn't thinking on that, but now I am :D I don't use GObject in my code, should I?

> It seems that the pthread library itself requires at least that pthread_init()
> be called once before using threads, is it called implicitly by every
> function that might require threads ? (like g_mutex_init() ?)

        Ok, as I am using glib 2.28, so I am calling g_thread_init before g_type_init now, what seems to be 
the correct thing, right?
        I would like to use the newest version of glib, but I am running it at work (I convinced guys here to 
use a bit of open source in the project) and I just wasn't able to compile libffi on the HPUX. My glib and 
all its dependencies are running in 32 bit and it seems libffi needs 64 bits to compile.

> Speaking of which, I just stumbled on some really odd documentation
> for g_mutex_init(), it says there:
>    "It is not necessary to initialize a mutex that has been created
> that has been statically allocated."

        I am getting an issue related to it here. I just used the following bit of code in a method:

138    static GStaticMutex get_mutex = G_STATIC_MUTEX_INIT;
139    do {
140       /* get next entry from file */
141       g_static_mutex_lock (&get_mutex);
142       get_status = server->events->get_next_data_entry(f, server->user_data, data_entry);
143       g_static_mutex_unlock (&get_mutex);
144       /* generate on process event */

        My program generates a core file at line 141. Am I doing something wrong?
        I had given up using GFile functions because something similar was occurring when calling g_file_new. 
I opened the core file using gdb and g_file_new was generating a core file in the point where glib function 
"g_io_modules_ensure_extension_points_registered"  a G_LOCK (giomodule.c).
        I compiled glib 2.28.6 on a HPUX unix:
uname -a
HP-UX BRUX0001 B.11.31 U 9000/800 HP-UX

        Any hint of what I could look for to find why is G_LOCK generating a core dump?


Esta mensagem, incluindo seus eventuais anexos, pode conter informaÃÃes confidenciais, de uso restrito e/ou 
legalmente protegidas. Se vocà recebeu esta mensagem por engano, nÃo deve usar, copiar, divulgar, distribuir 
ou tomar qualquer atitude com base nestas informaÃÃes. Solicitamos que vocà elimine a mensagem imediatamente 
de seu sistema e avise-nos, enviando uma mensagem diretamente para o remetente e para postmaster claro com br 
 Todas as opiniÃes, conclusÃes ou informaÃÃes contidas nesta mensagem somente serÃo consideradas como 
provenientes da Claro ou de suas subsidiÃrias quando efetivamente confirmadas, formalmente, por um de seus 
representantes legais, devidamente autorizados para tanto.
------------------------------------------------------------------------------
Este mensaje, incluyendo sus eventuales archivos adjuntos, puede contener informaciones confidenciales, de 
uso restringido y/o legalmente protegidas. Si usted ha recibido este mensaje por error, no debe utilizar, 
copiar, divulgar, distribuir o tomar cualquier actitud basada en estas informaciones. Solicitamos la 
inmediata eliminaciÃn del mensaje de su sistema y el envÃo de un informe en forma directa al remitente y a 
postmaster claro com br  Todas las opiniones, conclusiones o informaciones contenidas en este mensaje 
solamente serÃn consideradas como provenientes de Claro o de sus subsidiarias cuando sean efectivamente 
confirmadas, formalmente, a travÃs de uno de sus representantes legales debidamente autorizados a tal fin.
------------------------------------------------------------------------------
This message, including all attachments transmitted with it may include restricted, legally privileged, 
and/or confidential information. If you received this message by mistake or in error you are hereby notified 
that you must not use, publicize, copy, distribute, resend, or take any action based on the information 
contained in the message. We ask you to delete the message immediately from your system and advise us by 
sending a message directly