Recherche avancée

Médias (91)

Autres articles (58)

  • Les statuts des instances de mutualisation

    13 mars 2010, par

    Pour des raisons de compatibilité générale du plugin de gestion de mutualisations avec les fonctions originales de SPIP, les statuts des instances sont les mêmes que pour tout autre objets (articles...), seuls leurs noms dans l’interface change quelque peu.
    Les différents statuts possibles sont : prepa (demandé) qui correspond à une instance demandée par un utilisateur. Si le site a déjà été créé par le passé, il est passé en mode désactivé. publie (validé) qui correspond à une instance validée par un (...)

  • Problèmes fréquents

    10 mars 2010, par

    PHP et safe_mode activé
    Une des principales sources de problèmes relève de la configuration de PHP et notamment de l’activation du safe_mode
    La solution consiterait à soit désactiver le safe_mode soit placer le script dans un répertoire accessible par apache pour le site

  • ANNEXE : Les plugins utilisés spécifiquement pour la ferme

    5 mars 2010, par

    Le site central/maître de la ferme a besoin d’utiliser plusieurs plugins supplémentaires vis à vis des canaux pour son bon fonctionnement. le plugin Gestion de la mutualisation ; le plugin inscription3 pour gérer les inscriptions et les demandes de création d’instance de mutualisation dès l’inscription des utilisateurs ; le plugin verifier qui fournit une API de vérification des champs (utilisé par inscription3) ; le plugin champs extras v2 nécessité par inscription3 (...)

Sur d’autres sites (9407)

  • h264 : don’t sync pic_id between threads.

    3 avril 2017, par Ronald S. Bultje
    h264 : don’t sync pic_id between threads.

    This is how the ref list manager links bitstream IDs to H264Picture/Ref
    
objects, and is local to the producer thread. There is no need for the
    
consumer thread to know the bitstream IDs of its references in their
    
respective producer threads.
    

    In practice, this fixes tsan warnings when running fate-h264 :
    

    WARNING : ThreadSanitizer : data race (pid=19295)
    
  Read of size 4 at 0x7dbc0000e614 by main thread (mutexes : write M1914) :
    
    #0 ff_h264_ref_picture src/libavcodec/h264_picture.c:112 (ffmpeg+0x0000013b3709)
    
[..]
    
  Previous write of size 4 at 0x7dbc0000e614 by thread T2 (mutexes : write M1917) :
    
    #0 build_def_list src/libavcodec/h264_refs.c:91 (ffmpeg+0x0000013b46cf)
    • [DH] libavcodec/h264_picture.c

  • dnxhd : initialize DNXHDContext::avctx to each thread’s respective one.

    28 mars 2017, par Ronald S. Bultje
    dnxhd : initialize DNXHDContext::avctx to each thread’s respective one.

    Otherwise all thread’s private contexts have the avctx pointer set to
    
the AVCodecContext of the first thread, which means all writes to
    
ctx->avctx->* (in e.g. read_header) are effectively race conditions.
    

    Fixes fate-dnxhd under tsan.
    • [DH] libavcodec/dnxhddec.c

  • lagarith : assign correct per-thread value to LagarithContext::avctx.

    29 mars 2017, par Ronald S. Bultje
    lagarith : assign correct per-thread value to LagarithContext::avctx.

    This fixes race conditions reported by tsan in fate-lagarith. The races
    
were because each thread’s LagarithContext::avctx was set to the first
    
thread’s AVCodecContext.
    • [DH] libavcodec/lagarith.c

Navigation