Hi,
depuis le 28 juillet, le “core” de libplayer a subit une très grosse refonte. La raison principale était l’impossibilité d’auto-piloter libplayer depuis l’intérieur. Par exemple il n’était pas possible d’ordonner à libplayer de passer au morceau suivant depuis le callback. La raison est assez simple, le callback était (et est toujours) exécuté en parallèle au reste de la librairie. Appeler les routines pour changer de morceau aurait pu avoir de graves conséquences si depuis l’API public, le programme basé sur libplayer faisait la même chose dans le même intervalle de temps. En résumé, libplayer n’était tout simplement pas thread-safe.
Désormais ceci n’est plus qu’un souvenir. libplayer peut gérer des appels multiples et concourants sur “presque” toute l’API publique. Oui “presque”, car les fonctions d’init/uninit sont évidemment mandataires sur toutes les autres fonctions. Et les appels parallèles doivent se limiter à une même instance de player_t. Il y a également quelques fonctions uniquement réentrantes qui ne sont utiles qu’à la gestion des instances pour les MRLs.
Le diagramme ci-dessous résume assez bien le fonctionnement interne du nouveau libplayer:
Il y a grosso-modo deux threads principaux. Tout d’abord le superviseur qui va gérer toutes les entrées de l’API qui sont thread-safes et un gestionnaire d’événements qui va s’occuper de renvoyer les événements au callback interne puis au callback public tout en restant synchronisé avec le superviseur. Quelques explications plus techniques sont disponibles dans ce fichier de documentation.
A bientôt
Mathieu SCHROETER
