Discussion :

[nanosoft]

Bonjour,

J’utilise les Timers de la SDL 1.2 et je me pose une question à ce sujet :
L’exécution de la fonction de CallBack du Timer est-elle réalisée dans un autre thread parallèle ou est-ce le thread principal qui est interrompu lors de l’exécution du CallBack ?
Je me pose cette question pour le risque d’accès concurrents en mémoire, comment peut-on se protéger si il s’agit de 2 threads parallèles ?

[Bousk]

Salut,

oui comme la doc l'indique, la callback est appelée sur son propre thread.
Cette même doc présente un exemple pour transférer la callback au thread principal, en passant par un évènement.

Sinon tu peux directement utiliser SDL_GetTicks pour gérer ton propre timer.

[nanosoft]

Merci pour la réponse.
Dans la doc SDL 1.2 je n’avais pas vu cet article mais j’ai peut-être mal cherché.
J’utilise actuellement un UserEvent comme interruption en restant dans le même thread mais c’est un peu moins souple : il faut passer en boucle pour tirer les évènements alors qu’une routine de CallBack est appelée immédiatement.

[Bousk]

je n’avais pas vu cet article mais j’ai peut-être mal cherché

C'est le premier résultat google pour "SDL timer" et aussi le premier résultat pour "timer" sur la doc en elle-même. (Je suppose qu'en connaissant le nom de la fonction les résultats sont encore plus simples à retrouver, mais je ne le connaissais alors pas)

il faut passer en boucle pour tirer les évènements

Tu dois de toutes façons tirer tous les évènements en file d'attente à chaque frame. En quoi ajouter un évènement serait un problème ?

une routine de CallBack est appelée immédiatement.

Mais si ta callback doit utiliser des données qu'un autre thread utilise aussi, tu vas devoir mettre des locks ou transférer son exécution au thread principal. Donc l'aspect immédiat... ne l'est pas tant au final.

[nanosoft]

Salut,

L’utilisation envisagée était de réaliser un « timeout » en monothread lorsque l’exécution d’une tache un peu longue est en cours et pendant ce temps là on ne peut pas tirer les évènements.

Mais tu as raison de me renvoyer à la doc, je n’avais regardé que la 1.2 et en regardant à nouveau effectivement j’ai vu ceci :

« The timer callback function may run in a different thread than your main constant, and so shouldn't call any functions from within itself. »

[Bousk]

S'agit-il d'un projet de jeu ? Si oui, tu ne devrais pas avoir de tâche "trop longue" au point de bloquer le thread principal aussi longtemps.
Les tâches longues (type chargement de fichier) devraient être faîtes sur un thread différent. Généralement on a un système de jobs pour ça, le main thread pousse un job et récupère un handle, le job thread l'exécute, puis le main thread peut vérifier l'état du job via le handle.
Si le thread principal bloque trop longtemps, ta fenêtre va passer en "pas de réponse" et le système va la considérer comme bloquée/morte. Aussi sur certaines plateformes tu as des appels à exécuter à chaque frame pour s'assurer que le jeu n'est pas bloqué également. Et chaque frame ne peut durer plus de X secondes (généralement 5 de mémoire). Ceci pour permettre aux plus petites productions de ne pas s'embêter avec un thread de chargement de fichiers, tant qu'ils sont peu nombreux et rapides à traiter.

[nanosoft]

Oui c’est un projet de jeu.
Je suis bien conscient de toutes tes recommandations, au final je vais m’orienter comme tu le proposes mais au début je me demandais si je ne pourrais pas simplifier avec une réalisation monothread.

[Bousk]

Si tu veux faire simple, gardes ton système actuel et aies des chargements bloquants et opérations longues bloquantes sur le main thread.