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-boun...@gnome.org
[mailto:gtk-app-devel-list-boun...@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; jcup...@gmail.com
Cc: gtk-app-devel-list@gnome.org
Assunto: RES: mutex doubt
Hello,
-----Mensagem original-----
De: tristan.van.ber...@gmail.com [mailto:tristan.van.ber...@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 postmas...@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 postmas...@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
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
