# Gemfile fast\_xor Plattform auf :ruby aktualisieren

**URL:** <https://meta.discourse.org/t/update-gemfile-fast-xor-platform-to-ruby/159064>\
**Category:** Development\
**Created:** [28. Juli 2020 um 14:41 UTC](https://meta.discourse.org/t/update-gemfile-fast-xor-platform-to-ruby/159064 "2020-07-28T14:41:43Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)\
**Post date:** [30. Juli 2020 um 00:39 UTC](https://meta.discourse.org/t/update-gemfile-fast-xor-platform-to-ruby/159064/5 "2020-07-30T00:39:14Z")

</div>

> [@Falco](#):
>
> Ja. Jetzt, wo [wasm](https://github.com/wasmerio/ruby-ext-wasm) existiert, könnte das ein Ausweg sein.

Wasm wäre hier definitiv keine Option; die Nutzlast wäre viel größer, und es gibt zahlreiche Sicherheitsprobleme im Zusammenhang mit der korrekten Ausführung unter CSPs (und CORS-Bedenken). Die Implementierung von [markdown-it](https://github.com/markdown-it/markdown-it) ist außerordentlich schnell und erweiterbar, was eine Vielzahl von Plugins und ein riesiges bestehendes Ökosystem ermöglicht.

Nur noch etwas mehr Kontext zu mini\_racer: Von Anfang an bei Discourse haben wir auf eine einzige Pipeline zur Verarbeitung von Markdown bestanden. Das hat eine sehr unangenehme Klasse von Fehlern vollständig eliminiert, die ich bei Stack Overflow erlebt habe, bei denen Server und Client leicht unterschiedliche Dialekte sprachen. Für Discourse ist dies noch wichtiger, da Plugins die Pipeline anpassen können. Zum Beispiel:

◀ wird in einem Plugin implementiert (Parsing von `[]`)

> [@eregon](#):
>
> Kann Discourse stattdessen auf Puma laufen? Ist dafür eine Konfiguration erforderlich?

Wir haben einige „Lebensqualitäts“-Funktionen, die wir durch die Nutzung von Unicorn und die Abhängigkeit vom Forking erhalten, siehe:

> <https://github.com/discourse/discourse/blob/620c223d50bdaa776169574a7d376f056f9dec1c/config/unicorn.conf.rb>

Insbesondere überwachen und verwalten wir einen Sidekiq-Kindprozess vom Master-Prozess aus.

Aber… Truffle hat keine GIL, Puma ist bereits in der Gemfile enthalten, sobald mini\_racer funktioniert. Wir könnten an einer speichersparenden Truffle-Konfiguration zusammenarbeiten, die Sidekiq und Puma im selben Prozess hält. Oder Benutzer könnten einfach einen Sidekiq-Prozess manuell starten. Puma kann definitiv funktionieren; wir nutzen Rack.hijack ausgiebig, aber das ist bereits in Puma/Unicorn/Passenger implementiert.

---

_[View the full topic](https://meta.discourse.org/t/update-gemfile-fast-xor-platform-to-ruby/159064)._
