Piszę program w Ruby, który będzie miał nieskończoną pętlę główną, oraz jednocześnie aplikację w Railsach, przy pomocy której user będzie mógł odczytywać / zadawać parametry. Planowałem zrealizować to w ten sposób, komunikując się miedzy programami przy pomocy socketów, ale zacząłem się zastanawiać czy nie przekombinowałem. Czy nie istnieje jakiś prostszy sposób na umieszczenie pętli głównej w Railsach i odczytywanie / zadawanie wartości parametrów przy pomocy kontrolerów? Ewentualnie czy istnieje jakieś inne rozwiązanie niż Railsy które umożliwiłoby rozwiązanie problemu?
Wow. Przekombinowałeś.
Jeśli chcesz używać socketów to najprościej będzie pozostać przy czystym Ruby.
Rails można powiedzieć działa już w pętli. Jest nią serwer http, który odpowiedzialny jest za odbieranie requestów i wysyłanie odpowiedzi.
User ma mieć dostęp do interfejsu z poziomu przeglądarki, będzie to conajmniej kilka stron, docelowo uwierzytelnianie etc, jesteś pewien, że najprościej będzie klepać to samemu w Ruby?
Nie czuję potrzeby używania socketów, wygooglowałem to jako prostą opcję komunikacji między programami w Ruby, jeżeli istnieje lepsza alternatywa będę wdzięczny - nie mam zbyt dużego doświadczenia w temacie.
Ok, Railsy działają w pętli - w którym miejscu mogę wstawić własną nieskończoną pętlę, która będzie non stop wykonywała obliczenia, i jak komunikować się między nią a kontrolerami (przekazywanie parametrów w obie strony)?
Może opisz dokładnie co te programy mają robić. Jak ma wygląda interakcja użytkownika z aplikacją Rails i co będzie przetwarzane po stronie serwera.
Redis - użyj jako bazę danych do współdzielenia tych parametrów pomiędzy procesami. Możesz użyć też mechanizmu pub-sub, choć raczej tylko w jedną stronę (rails -> apka z pętlą). Jeśli chcesz, by działało to także w drugą stronę (np. powiadomienie do klienta, że proces się zakończył) musisz użyć socketów albo odpytuj serwer co jakiś czas - to zależy od specyfikacji problemu.
Program ma odpowiadać za sterowanie robotem, przetwarzanie instrukcji wyższego poziomu na parametry wysyłane do arduino, do tego czytanie odczytów sensorów z arduino i przesyłanie ich do Railsów. Czyli pośredniczenie w komunikacji w obie strony + obliczenia.
Railsy mają udostępniać użytkownikowi interfejs do zadawania / odczytywanie parametrów przez internet, docelowo streaming z kamery.
Taka była idea, jeżeli podchodzę do tego od złej strony to oczywiście będę wdzięczny za oświecenie 
Wymagane jest ciągłe wykonywanie się algorytmów i możliwość przesyłania danych w obie strony na linii arduino <-> algorytmy sterujące <-> user, przez internet.
@pttr Dzięki, przyjrzę się obu rozwiązaniom.
Użycie socketów, albo innego dowolnego mechanizmu IPC to bardzo dobry pomysł. Ba, nic nie stoi na przeszkodzie, żeby w tej aplikacji też używać HTTP w postaci prostej np. Sinatry (albo nawet Railsów 
), bo obliczenia i tak muszą być na innym wątku (albo całej puli wątków) niż serwer komunikujący się.
Jeżeli zadania mają charakter kolejki to możesz też użyć rozwiązania z kolejkami (AMQP)
Ewentualnie możesz mieć jeszcze uruchomić aplikację obliczeniową w tym samym procesie co Railsy, ale w innym wątku. W takim przypadku musisz mieć uruchomione Railsy najlepiej na serwerze opartym na wątkach (np. Puma).
Moim zdaniem jednak rozdzielenie to zdrowsze podejście, jeżeli w przyszłości aplikacja ma być skalowalna. Jeżeli potrzebujesz Railsy tylko do sterowania jednym urządzeniem i to jeszcze na tym samym urządzeniu, to rozwiązanie tylko z wątkami będzie optymalne dla tego konkretnego problemu.