Forking / separate process / reactor-based model instead of using threads?

[suan]

@ysbaddaden Have you ever considered using a separate process model instead of a threading model for each app? For a given app, pow doesn't actually use multiple threads, which allows you to run un-threadsafe code.

This is the dilemma we're having with our environment on Linux now - whether to use prax or make our multiple apps' code threadsafe. (since thus far we've only used unicorn and pow)

My thinking is that a process-based solution would be more compatible with various apps.

P/S: You've been super helpful with your quick fixes with my other issues!

[suan]

70 at least allows me to sidestep the issue

[ysbaddaden]

No, I haven't considered a process-based concurrency. I considered an event loop, using eventmachine, but threads are core to the language, and not hard to deal with in Prax; it doesn't share any data cross threads, and just have to be careful when starting and killing apps. Also, threads are keeping the memory usage low.

I never considered how problematic it could be in apps, thought. All my applications run on Puma and I never share any data across requests —or I push it to the database or Sidekiq workers.

[suan]

Yeah, I think it might be a surprise to many who are porting their apps over from pow cause AFAIK unicorn is still very widely used for prod and many places still don't bother too much about thread safety for Rails apps. I know I spent spent more than a day tracking down something that was failing only on Linux, only to find it was due to threading issues.

In the meantime I've put a README disclaimer in #71

[ysbaddaden]

I'm wondering: isn't Rails < 4 using Rack::Lock or an equivalent middleware to isolate requests in a threaded/evented environment? It can still be injected for Rails >= 4 and other Rack applications, can't it?

Note: I'm not against an evented version of prax/racker instead of the current threaded model (using celluloid-io or eventmachine). It may actually suit the project better. But I won't be working on it actively anytime soon, and I'm not sure it would fix the concurrency problem.

[ysbaddaden]

Closing because I don't foresee any free time to work on an evented server. Maybe someday I'll work on a simpler solution, using an existing Rack server to leverage a lot of code.