Fibres et threads de niveau utilisateur
Sous Windows, chaque fibre libSceFiber est une vraie fibre Windows, de sorte qu'un basculement conserve les registres invités et la pile invitée. Les threads de niveau utilisateur démarrent par le même chemin pthread.
Notes du dépôt jusqu’au 10 octobre 2026
Pourquoi une fibre ne peut pas être une opération vide
Le code invité s'exécute comme du code machine natif. Un basculement de fibre doit reprendre les registres exacts et la pile exacte, avec des cadres hôtes et des cadres invités mélangés sur cette pile. Renvoyer le succès depuis sceFiberSwitch sans basculer laisserait le titre continuer sur la mauvaise pile et corrompre les deux côtés.
PS5PCEM adosse chaque fibre invitée initialisée à une fibre Windows. sceFiberRun, sceFiberSwitch et sceFiberReturnToThread utilisent ce mécanisme. Le thread qui a appelé sceFiberRun est la fibre racine. L'enregistrement public SceFiber de 128 octets conserve les signatures d'ABI, l'état, l'argument d'entrée, le nom et la plage de contexte fournie par l'appelant.
À qui appartient la pile
Le titre fournit un tampon de contexte, et ce tampon est enregistré dans l'objet d'ABI. Windows possède la pile réelle. Utiliser le tampon du titre comme pile Windows native sauterait la page de garde et la comptabilité de déroulement que le système d'exploitation exige. Le contexte minimal attendu par l'enregistrement de micrologiciel est tout de même vérifié, ainsi que l'alignement et les signatures de début et de fin.
sceFiberGetSelf, la finalisation, les vérifications de propriété entre threads et la réinitialisation à l'exécution sont implémentés. Le backend existe sur la cible d'exécution native Windows x86-64. Les autres hôtes peuvent construire le reste de l'émulateur, et ce chemin de basculement n'y est pas disponible.
Threads de niveau utilisateur
L'initialisation et la finalisation de libSceUlt réussissent pour qu'un système de travaux du titre puisse démarrer. Les environnements d'exécution, les files d'attente, les pools de données de file, les mutex, les sémaphores et les files conservent un état côté hôte indexé par les objets que le titre a alloués. Les éléments de travail eux-mêmes démarrent par le chemin pthread existant. Les requêtes de taille de zone de travail renvoient les tailles alignées que ces créations attendent.
Les files d'événements user-edge du noyau partagent la même attente sensible à la séquence que la synchronisation pthread. Le filtre VideoOut -13 et le filtre graphique -14 empruntent cette file et conservent l'identifiant et les données utilisateur de chaque enregistrement. ULT est de la colle d'ordonnancement. Il n'ajoute pas un second émulateur de CPU.
Ce qui est en place
- Fibres Windows pour sceFiberRun, sceFiberSwitch et sceFiberReturnToThread.
- Signatures d'ABI, vérifications de propriété et pile possédée par l'hôte avec une page de garde.
- Initialisation ULT, files, mutex, sémaphores et éléments de travail adossés à pthread.
- Files d'événements user-edge partagées avec l'achèvement VideoOut et graphique.
Ce qui manque encore
- Le basculement de fibre existe sous Windows x86-64. Les autres systèmes d'exploitation hôtes n'exécutent pas le code invité nativement.
- Une fibre n'est pas un thread matériel ordonnancé de façon préemptive.
- ULT n'implémente pas un interpréteur distinct pour les corps de travail.
Mécanismes liés
Ce que ces pages décrivent