Is there a cleaner way of hooking into the event loop?

Is there a cleaner way of hooking into the event loop?

[Sam Saffron]

I am spawning sidekiqs from the master process so I share memory
better, added this patch

https://github.com/discourse/discourse/commit/4aaedb82d09d53159a99c3c94c0232c3cf5b0725

Thing is I need to be in the master thread for both checks and
spawning cause of this https://bugs.ruby-lang.org/issues/9751

Is there a cleaner way to hook in?
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: Is there a cleaner way of hooking into the event loop?

[Michael Fischer]

On Tue, Apr 22, 2014 at 6:21 PM, Sam Saffron <sam.saffron@gmail.com> wrote:
> I am spawning sidekiqs from the master process so I share memory
> better, added this patch
>
> https://github.com/discourse/discourse/commit/4aaedb82d09d53159a99c3c94c0232c3cf5b0725
>
> Thing is I need to be in the master thread for both checks and
> spawning cause of this https://bugs.ruby-lang.org/issues/9751
>
> Is there a cleaner way to hook in?

>From an operational perspective this seems like a significant
premature optimization.  I'd think twice before doing it.  IME you
really don't want asynchronous job handling in the same process space
as a synchronous preforking webserver.  Best to keep your concerns
separated.  And RAM is cheap.

--Michael
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: Is there a cleaner way of hooking into the event loop?

[Sam Saffron]

"like a significant premature optimization."

Funny, tell that to the people freaking out about Discourse's minimum
RAM requirements :), it clearly saves 50-60MB on PSS which is pretty
handy.

On Wed, Apr 23, 2014 at 11:30 AM, Michael Fischer <mfischer@zendesk.com> wrote:
> On Tue, Apr 22, 2014 at 6:21 PM, Sam Saffron <sam.saffron@gmail.com> wrote:
>> I am spawning sidekiqs from the master process so I share memory
>> better, added this patch
>>
>> https://github.com/discourse/discourse/commit/4aaedb82d09d53159a99c3c94c0232c3cf5b0725
>>
>> Thing is I need to be in the master thread for both checks and
>> spawning cause of this https://bugs.ruby-lang.org/issues/9751
>>
>> Is there a cleaner way to hook in?
>
> >From an operational perspective this seems like a significant
> premature optimization.  I'd think twice before doing it.  IME you
> really don't want asynchronous job handling in the same process space
> as a synchronous preforking webserver.  Best to keep your concerns
> separated.  And RAM is cheap.
>
> --Michael
> _______________________________________________
> Unicorn mailing list - mongrel-unicorn@rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> Do not quote signatures (like this one) or top post when replying
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: Is there a cleaner way of hooking into the event loop?

[Eric Wong]

Sam Saffron <sam.saffron@gmail.com> wrote:
> I am spawning sidekiqs from the master process so I share memory
> better, added this patch
> 
> https://github.com/discourse/discourse/commit/4aaedb82d09d53159a99c3c94c0232c3cf5b0725
 
> Thing is I need to be in the master thread for both checks and
> spawning cause of this https://bugs.ruby-lang.org/issues/9751

I'll try to take a look at that, soon[1]

> Is there a cleaner way to hook in?

Not really.  I can't promise no changes, but at least you told us about
it.

I don't want to encourage apps written specifically for unicorn and
defeating the point of Rack, either; but I don't imagine unicorn
changing much[2] until Rack 2.0 (if that ever happens?)


[1] - Most of my energy is devoted public-inbox.org right now.
      With the imminent death of the Rubyforge lists,
      Free Software extremist-console-junkies like me need
      to keep distributed communication alive and usable to
      non-GUI users.

[2] - Obvious the mailing list will change :P
      And probably some wankery in providing an nginx alternative
      via yahns[3], but this won't change unicorn itself.

[3] - allowing for lazy buffering on streaming output
      and selectively handling MT-safe endpoints yahns,
      while proxying non-MT-safe endpoints to unicorn...