* Is there a cleaner way of hooking into the event loop?
@ 2014-04-23 1:21 Sam Saffron
2014-04-23 1:30 ` Michael Fischer
2014-04-23 8:54 ` Eric Wong
0 siblings, 2 replies; 4+ messages in thread
From: Sam Saffron @ 2014-04-23 1:21 UTC (permalink / raw)
To: unicorn list
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Is there a cleaner way of hooking into the event loop?
2014-04-23 1:21 Is there a cleaner way of hooking into the event loop? Sam Saffron
@ 2014-04-23 1:30 ` Michael Fischer
2014-04-23 2:04 ` Sam Saffron
2014-04-23 8:54 ` Eric Wong
1 sibling, 1 reply; 4+ messages in thread
From: Michael Fischer @ 2014-04-23 1:30 UTC (permalink / raw)
To: unicorn list
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Is there a cleaner way of hooking into the event loop?
2014-04-23 1:30 ` Michael Fischer
@ 2014-04-23 2:04 ` Sam Saffron
0 siblings, 0 replies; 4+ messages in thread
From: Sam Saffron @ 2014-04-23 2:04 UTC (permalink / raw)
To: unicorn list
"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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Is there a cleaner way of hooking into the event loop?
2014-04-23 1:21 Is there a cleaner way of hooking into the event loop? Sam Saffron
2014-04-23 1:30 ` Michael Fischer
@ 2014-04-23 8:54 ` Eric Wong
1 sibling, 0 replies; 4+ messages in thread
From: Eric Wong @ 2014-04-23 8:54 UTC (permalink / raw)
To: unicorn list; +Cc: Sam Saffron
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...
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-04-23 9:30 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-23 1:21 Is there a cleaner way of hooking into the event loop? Sam Saffron
2014-04-23 1:30 ` Michael Fischer
2014-04-23 2:04 ` Sam Saffron
2014-04-23 8:54 ` Eric Wong
Code repositories for project(s) associated with this public inbox
https://yhbt.net/unicorn.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).