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-***@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

[Michael Fischer]

Post by 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?
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-***@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

[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.

Post by Michael Fischer

Post by 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?
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
_______________________________________________
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

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

[Clara Anne]

Sam

Where are you now. are you busy ? if u don't have any credit card to verify ur identity then u can create a free acc here, u dont need any cc or anything...just add ur email. I have profile here too but not often i use it. but for u i will login there today..
http://clara9031.wemeetsafely.com/ my user id : clara9031
go to my profile link and create a free acc..send a message there..i will reply after few minutes.
thanks.

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

[Eric Wong]

Post by 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

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

Post by Sam Saffron
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...
_______________________________________________
Unicorn mailing list - mongrel-***@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying