Single loop vs 2 threads

[barnack]

Greetings,
I'm working on a program (non game) which would have long times of non-interaction with the user. (think to some explorer windows for example, you maybe drag something and keep the window open there doing nothing.
Since i'd not need a constant "game loop", but things happen only when the user does something i've use waitEvent instead of pollEvent. (it's not a game, i don't want it to suck computer resources, i want it to use as little as exactly needed).

Now, let's suppose i want to add an animation in the background (some particles effect), which in NO way depend on user input. They're just there, do they thing with 0 interaction, they just update coordinates, create and destroy. Again since it's not a game supposed to get the most out of my resources, for this i'd use a fixed-time step with sleep (don't even need precise timing, just *some* timing). I don't want it to update 500 times per second really; 30 is already fine enough.

Now my question is, since the particles are just a constantly flowing effect and have nothing to do with user interaction, should i:

• Use poll event in the same fixed-time step loop that handles particles.
• Use one thread for particles, which updates 30 times per second, and another thread for handling input.

I'm more towards the second idea because of the following reasons:
the two loops work with totally different things, it'd also help separating them logically. Since they don't affect each other in any way, i'd not even need to use mutex guards when performing calculations, because nothing is shared.

But now comes my concern: how can i handle drawing? Particles should update the drawing 30 times per second, while the input loop should update the drawing only when the user does something. To do so each loop would have to access some of the other loop's data (for example if input loop is drawing i need to get particles coordinates as well, don't want them to disappear in between two frames). I'd have to use mutexes for the short time the drawing cycle is accessing coordinates from the other's cycle.

When i came to that conclusion i started guessing… well maybe i should just smash everything in the same cycle and gg.
But since i usually tend to prefer splitting things that have nothing to do with each other, i'd love to see suggestions about the second implementation...

_________________________________________________________________
Just thought a thing:
can i have the input loop draw in memory a "temporary image" and the particles loop draw that temporary image on screen with then the particles on top of it? That way all i'd have to do is protecting with a single mutex the access to said temporary image! Does it work in your mind?

[eXpl0it3r]

Multi-threading will introduce quite a bit of complexity (read: you will create a lot of unnecessary bugs) and it requires sone more advanced knowledge to pull it off properly.

What does it matter whether a separate thread is running a render loop or whether your main thead is doing so? Just setFramerateLimit to 15-30fps and use pollEvent.