[RAILS] À propos du problème de blocage dans le traitement parallèle dans la version 4.0 de gem'sprockets

À propos de gem'sprockets '

Une bibliothèque qui compile des fichiers de bonbons. Cependant, à partir de rails 5.1, webpacker est recommandé pour le compilateur javascript, et à partir de rails 6.0, la valeur par défaut pour le compilateur javascript a été changée en webpacker. Actuellement utilisé par défaut pour le CSS et la compilation d'images.

CSS, image -> sprockets javascript -> webpacker

phénomène

Le résultat de l'exécution ne sera pas renvoyé par la précompilation de l'actif.

Solutions

1. Définissez les paramètres pour désactiver le traitement parallèle.

En définissant l'une des options suivantes dans les paramètres de l'application, le traitement parallèle est désactivé et des problèmes surviennent.

Rails.config.assets.export_concurrent = false
Sprockets.export_concurrent = false

2. Utilisez la version 3 des pignons

La maintenance des gem'sprockets est lente et on s'attend à ce que cela prenne du temps à réparer, c'est donc une série d'utiliser 3 séries.

Détails

Sprockets 4.0 est désormais multithread et parallèle pour améliorer les performances de compilation. See: https://github.com/rails/sprockets/pull/469

Le traitement simultané utilise Concurrent :: Promise puis wait! ʻIn promises.each (&: wait!)`.

promises = args.flatten.map do |path|
  Concurrent::Promise.execute(executor: executor) do
    environment.find_all_linked_assets(path) do |asset|
      yield asset
    end
  end
end
promises.each(&:wait!)

See: https://github.com/rails/sprockets/pull/469/files#diff-0d972076f2fbe7a73281fcc0282e57a1618bba231bc8023a4d5bc5705fb06da7R123-R130

À ce stade, la méthode wait! Attend le délai d'expiration jusqu'à ce que le traitement soit terminé, mais comme aucun argument n'est spécifié, nil est entré et elle attend indéfiniment.

def wait!(timeout = nil)
  wait(timeout).tap { raise self if rejected? }
end

See: https://github.com/ruby-concurrency/concurrent-ruby/blob/ffed3c3c0518030b0ed245637703089fa1f0eeee/lib/concurrent/concern/obligation.rb#L79-L89

Si un blocage se produit pendant la concurrence, le processus de précompilation des actifs ne s'arrêtera jamais. Il semble que plusieurs threads se bloquent en essayant de compiler le même fichier lors du traitement en parallèle. bug de ruby-concurrence? Il y a une possibilité de. https://github.com/ruby-concurrency/concurrent-ruby/issues/870

Il existe également de nombreux problèmes similaires. See: https://github.com/rails/sprockets/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+thread+OR+concurrent

référence

https://github.com/rails/sprockets/issues/640 https://github.com/rails/sprockets/issues/581 https://github.com/ruby-concurrency/concurrent-ruby/issues/870 https://github.com/ruby-concurrency/concurrent-ruby/blob/ffed3c3c0518030b0ed245637703089fa1f0eeee/lib/concurrent/synchronization/lockable_object.rb#L6-L20

Autre

Des discussions sur les pignons peuvent également être trouvées sur la page WTF ci-dessous. https://discuss.rubyonrails.org/t/sprockets-abandonment/74371/24