* Re: dropping Ruby 1.8 support for unicorn 5?
2014-09-27 8:32 7% dropping Ruby 1.8 support for unicorn 5? Eric Wong
@ 2014-09-27 8:37 0% ` Ernest W. Durbin III
0 siblings, 0 replies; 3+ results
From: Ernest W. Durbin III @ 2014-09-27 8:37 UTC (permalink / raw)
To: Eric Wong; +Cc: unicorn-public
[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]
As the submitter of the referenced 1.8.6 patch *still ashamed* I can say that I fully support a 4.x series with “maintenance” level support.
Since the language won’t be changing, the 4.x series should be a very quiet branch indeed.
Onward, to greater things.
-Ernest
On Sep 27, 2014, at 4:32 AM, Eric Wong <e@80x24.org> wrote:
> We've brought this up a few times, but I suppose we might as well drop
> 1.8 support in a major version change.
>
> We may still maintain unicorn 4.x for 1.8 users indefinitely; after all,
> we only accepted a patch for 1.8.6 compatibility less than a year
> ago(!)[1]. So I'll still feel a _little_ bad for dropping 1.8 :x
>
> One big reason for this is it looks like Ruby will move towards
> deprecating old Data_* macros for superior (1.9+-only) TypedData_*
> macros in the next few years[2]. The theme for unicorn 5 is mostly
> dropping old, unused crap anyways; and not gaining new bloat.
>
> Worst case is we support 1.8 and avoid deprecation warnings through
> the use of ifdefs in the HTTP parser, but I'm no fan of ifdefs.
>
>
> [1] commit 7e9e4c740aba24096f768f578779dc1053cb8b70
> (construct listener_fds Hash in 1.8.6 compatible way)
>
> [2] http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=revision&revision=47717
> This is due to type-checking issues like
> https://bugs.ruby-lang.org/issues/10296
>
^ permalink raw reply [relevance 0%]
* dropping Ruby 1.8 support for unicorn 5?
@ 2014-09-27 8:32 7% Eric Wong
2014-09-27 8:37 0% ` Ernest W. Durbin III
0 siblings, 1 reply; 3+ results
From: Eric Wong @ 2014-09-27 8:32 UTC (permalink / raw)
To: unicorn-public
We've brought this up a few times, but I suppose we might as well drop
1.8 support in a major version change.
We may still maintain unicorn 4.x for 1.8 users indefinitely; after all,
we only accepted a patch for 1.8.6 compatibility less than a year
ago(!)[1]. So I'll still feel a _little_ bad for dropping 1.8 :x
One big reason for this is it looks like Ruby will move towards
deprecating old Data_* macros for superior (1.9+-only) TypedData_*
macros in the next few years[2]. The theme for unicorn 5 is mostly
dropping old, unused crap anyways; and not gaining new bloat.
Worst case is we support 1.8 and avoid deprecation warnings through
the use of ifdefs in the HTTP parser, but I'm no fan of ifdefs.
[1] commit 7e9e4c740aba24096f768f578779dc1053cb8b70
(construct listener_fds Hash in 1.8.6 compatible way)
[2] http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=revision&revision=47717
This is due to type-checking issues like
https://bugs.ruby-lang.org/issues/10296
^ permalink raw reply [relevance 7%]
* Re: [PATCH] construct listener_fds Hash in 1.8 compatible way
@ 2013-11-01 18:49 6% ` Eric Wong
0 siblings, 0 replies; 3+ results
From: Eric Wong @ 2013-11-01 18:49 UTC (permalink / raw)
To: unicorn list
"Ernest W. Durbin III" <ewdurbin@gmail.com> wrote:
> On Fri, Nov 1, 2013 at 1:46 PM, Hleb Valoshka <375gnu@gmail.com> wrote:
> > On 11/1/13, Ernest W. Durbin III <ewdurbin@gmail.com> wrote:
> >
> >> + LISTENERS.map do |sock|
> >
> > You mean LISTENERS.each, aren't you? :)
Yes, LISTENERS.each is correct here. Thanks for the catch!
> the call has been to `LISTENERS.map` as far back in the history of
> lib/unicorn/http_server.rb as i could find.
It used to be map because we wanted it to return an array. Now we don't
care for the return value, so I've tweaked it to each.
Pushed out the following, thanks all. Should have out 4.7.0 within
a few days (few more cleanups while we're at it).
>From 7e9e4c740aba24096f768f578779dc1053cb8b70 Mon Sep 17 00:00:00 2001
From: "Ernest W. Durbin III" <ewdurbin@gmail.com>
Date: Fri, 1 Nov 2013 10:12:33 -0400
Subject: [PATCH] construct listener_fds Hash in 1.8.6 compatible way
This renables the ability for Ruby 1.8.6 environments to perform reexecs
[ew: clarified this is for 1.8.6,
favor literal {} over Hash.new,
tweaked LISTENERS.map => LISTENERS.each, thanks to Hleb Valoshka
]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
lib/unicorn/http_server.rb | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/lib/unicorn/http_server.rb b/lib/unicorn/http_server.rb
index 2decd77..402f133 100644
--- a/lib/unicorn/http_server.rb
+++ b/lib/unicorn/http_server.rb
@@ -449,13 +449,14 @@ class Unicorn::HttpServer
end
self.reexec_pid = fork do
- listener_fds = Hash[LISTENERS.map do |sock|
+ listener_fds = {}
+ LISTENERS.each do |sock|
# IO#close_on_exec= will be available on any future version of
# Ruby that sets FD_CLOEXEC by default on new file descriptors
# ref: http://redmine.ruby-lang.org/issues/5041
sock.close_on_exec = false if sock.respond_to?(:close_on_exec=)
- [ sock.fileno, sock ]
- end]
+ listener_fds[sock.fileno] = sock
+ end
ENV['UNICORN_FD'] = listener_fds.keys.join(',')
Dir.chdir(START_CTX[:cwd])
cmd = [ START_CTX[0] ].concat(START_CTX[:argv])
--
1.8.4.483.g7fe67e6.dirty
_______________________________________________
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 related [relevance 6%]
Results 1-3 of 3 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2013-11-01 14:12 [PATCH] construct listener_fds Hash in 1.8 compatible way Ernest W. Durbin III
2013-11-01 17:46 ` Hleb Valoshka
2013-11-01 18:32 ` Ernest W. Durbin III
2013-11-01 18:49 6% ` Eric Wong
2014-09-27 8:32 7% dropping Ruby 1.8 support for unicorn 5? Eric Wong
2014-09-27 8:37 0% ` Ernest W. Durbin III
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).