Thread problems (issue 26)

[André Wagner]

I'm posting this to the list so we won't put all our discussion in the
issue list.

It's seems that when xsw is stressed against a big presentation, this
could cause a segfault. Apartently, the problem is in the threads, as
deactivating the threads would solve the problem.

I'll try to explain here how the threading system was initially
though, in order to help those who are looking for a solution.

The idea behind the threads is: when a presentation is open, all
"commands" are marked as *dirty*. (a "command" is a image that needs
to be loaded, or a text image that needs to be built). The presenter
starts then to load/build all command images. As soon as a command is
loaded/built, it is marked as "non-dirty" and stays on memory.

In the moment the presentation is open, this happens:

1. The commands of the first slides are loaded in the main thread
(function presenter_cache);
2. The first slide is shown in the screen;
3. A thread is started (presenter_cache_thread) where all commands
marked as dirty are loaded in sequence.

Eventually, the user will request the presenter to show a slide whose
commands are not yet loaded. This happens, for example, if the user
opens the presentation and immediately presses END. Then, this
happens:

1. The program asks the thread to leave (by setting pr->leave_thread
to 1) and waits;
2. Once the thread leaves, the commands referent to the new current
slide are loaded/built;
3. The slide is shown on the screen;
4. The thread is restarted. Since it will only load those commands
marked as dirty, it means it'll continue from where it stopped.

That's pretty much it. I'm investigating to code also to see what
might be hapeening. If you have any questions, don't hesitate in
asking.

Regards,

André

[chwo...@gmail.com]

Hopefully this won't post twice...I submitted this same post several
hours ago and google still hasn't updated the form...


We could have problems in the following situations

main thread: creates thread cache thread
cache thread: gets created doesn't run or execute
anything.
main thread: checks to see if thread is running.
it fails because cache thread
never set pr->thread_running to 1.
main thread will spawn another thread.
cache thread 2 : gets created doesn't run or execute
main thread: checks to see if thread is running.
it fails because cache thread
never set pr->thread_running to 1.
main thread will spawn another thread.
...

This could go on. the different cache threads
eventually partially run and mess things up since
they could be working on the same data.

We could in theory create hundreds of threads
if things get scheduled oddly.

So far the simplest way for this to be fixed
is to remove the lines

pr->thread_running = 1;
pr->leave_thread = 0;

from the presenter_cache_thread and
add them presenter_cache right before we
create another thread.

pr->thread_running = 1;
pr->leave_thread = 0;
pr->thread = SDL_CreateThread(presenter_cache_thread, pr);