threaded version of load_images_to_ram segfaults

[Marco Lazzaroni]

..while calling clutter_texture_set_from_rgb_data().

[Marco Lazzaroni (marcolazzaroni)]

it's quite strange. I set to run load_images_to_ram to a separate thread.
luce crashes inside clutter_texture_set_from_rgb_data() (it should at least return an error...)
if i call load_images_to_ram in the same thread, everything is ok
either I don't correctly setup the thread or ... i don't know

[Marco Lazzaroni (marcolazzaroni)]

see http://stackoverflow.com/questions/3831767/c-clutter-1-0-calling-function-from-thread-causes-segfault

The bug is not solved yet. I have to find a smart way to accomplish it, too.
Clutter function must be called from the same thread that called clutter_init and clutter main: I have to think about it.

[Marco Lazzaroni (marcolazzaroni)]

I have to decide whether it's better to call clutter_texture_set_from_rgb_data() in a "deterministic" way or waiting idle cycles of the clutter thread.

[Sergey "Shnatsel" Davidoff (shnatsel)]

I'm smoking threading manuals for a better solution, no results yet.

[Sergey "Shnatsel" Davidoff (shnatsel)]

I've noticed that _REENTRANT macro, required for safe threading (as my book says, it describes pthread in NTPL implementation). Is that OK?

[Sergey "Shnatsel" Davidoff (shnatsel)]

I meant that the book descibes pthread in NTPL implementation, and the macro is needed for replacing functions with reentrant equivalents (notably stdio buffered I/O), making errno variable thread-local and so on.

[Sergey "Shnatsel" Davidoff (shnatsel)]

And that phrase is incomplete anyway... I've noticed that the macro _REENTRANT is not declared. Is this OK?

This issue doesn't seem to be a problem when using pthread library, it has awesome pthread_exit() and pthread_join(). Just load the RGB data in a thread, and wait till the RGB-loading thread does its job in the clutter-calling thread with pthread_join(), which doesn't seem to waste CPU cycles.

See also: http://stackoverflow.com/questions/2156353/how-do-you-query-a-pthread-to-see-if-it-is-still-running

[Sergey "Shnatsel" Davidoff (shnatsel)]

g_thread_join() is the glib equivalent to pthread_join(). Will smoke some Luce code now, but (as you can see) my brainpower is low atm.

[Marco Lazzaroni (marcolazzaroni)]

If I get it right, I think that any consideration involves modifying clutter source, which is not a workable solution.

As stated in http://docs.clutter-project.org/docs/clutter/stable/clutter-General.html "The only safe and portable way to use the Clutter API in a multi-threaded environment is to never access the API from a thread that did not call clutter_init() and clutter_main()."

At the moment che source code of luce does NOT follow this rule.

Also, the following scheme is mandatory in a multi thread environment (and already implemented in luce):

int
main (int argc, char *argv[])
{
  /* initialize GLib's threading support */
  g_thread_init (NULL);

  /* initialize Clutter's threading support */
  clutter_threads_init ();

  /* initialize Clutter */
  clutter_init (&argc, &argv);

  /* program code */

  /* acquire the main lock */
  clutter_threads_enter ();

  /* start the main loop */
  clutter_main ();

  /* release the main lock */
  clutter_threads_leave ();

  /* clean up */
  return 0;
}

Also, "The common pattern for using threads with Clutter is to use worker threads to perform blocking operations and then install idle or timeour sources with the result when the thread finished.".

So my choice is either A) use idle time of the thread that called clutter_init by use of clutter_threads_add_idle() or B) insert the calls I need between clutter_init and clutter_main

Solution B) is good for everything that can be done in the inizialisation phase. Since I want to postpone some work after the inizialisation, the only workable solution is A).
I need some synchronization; I think I can get it with a semaphore, a token, or something similar.

[Marco Lazzaroni (marcolazzaroni)]

I have to try adding clutter_threads_enter / leave () around the clutter_* call in call_clutter_texture_set_from_rgb_data

[Marco Lazzaroni (marcolazzaroni)]

fixed by release 47. Now the texture realization is postponed to the moment of the refresh, while the loading is done in a separate thread at the beginning.

[Marco Lazzaroni (marcolazzaroni)]

I have addressed the problem with some mutexes. It barely works now :-)