headers
Eric Wong | 22 Nov 2009 09:18

Unicorn on Rubinius?

Hi all,

I've been working on the Unicorn HTTP server mostly in Ruby but the
C/Ragel HTTP parser is descended from the Mongrel one.  I've made the
parser compatible with Rubinius 0.13 as of commit
c89ce4fb958d79009feb18cea39b14ddf8b11ff5 in unicorn.git, however the
pure-Ruby parts do not appear to pass tests at the moment.

The Ruby parts of Unicorn are extremely *nix-oriented and uses a lot of
things that only work on *nix-like systems.  However, everything we do
is currently known to be working under 1.9.1, 1.8.7 and 1.8.6 (and I'm
committed to continue supporting Unicorn on MRI).

Since I'm already short on time/resources and unfamiliar with Rubinius
internals (or C++), but I thought you guys might be interested in
getting Unicorn to run under Rubinius since all the currently failing
parts are still pure Ruby, just not commonly-used Ruby.

Unicorn does a lot of Unix-only things that are uncommon in most Ruby
code:

* Working with unlinked Files (empty ones are also shared across
  parent+child and we do fchmod() on them).  We also buffer
  large uploads to unlinked File objects.  This seems to fail
  immediately at startup once the master forks off the worker
  since each worker gets a file descriptor it shares with
  the master.

* Iterating through ObjectSpace for File objects with the O_APPEND
  flag and File#sync=true, and then doing File#reopen on them.
(Continue reading)

Permalink | Reply |
headers
evanphx | 23 Nov 2009 18:28
Picon

Re: Unicorn on Rubinius?

Hi Eric!

Thanks for giving Rubinius a ride on the Unicorn. Sounds like you're
using a lot of features that we probably haven't yet sussed the bugs
out of, I'll address them more below.

On Nov 22, 12:18 am, Eric Wong <normalper... <at> yhbt.net> wrote:
> Hi all,
>
> I've been working on the Unicorn HTTP server mostly in Ruby but the
> C/Ragel HTTP parser is descended from the Mongrel one.  I've made the
> parser compatible with Rubinius 0.13 as of commit
> c89ce4fb958d79009feb18cea39b14ddf8b11ff5 in unicorn.git, however the
> pure-Ruby parts do not appear to pass tests at the moment.
>
> The Ruby parts of Unicorn are extremely *nix-oriented and uses a lot of
> things that only work on *nix-like systems.  However, everything we do
> is currently known to be working under 1.9.1, 1.8.7 and 1.8.6 (and I'm
> committed to continue supporting Unicorn on MRI).
>
> Since I'm already short on time/resources and unfamiliar with Rubinius
> internals (or C++), but I thought you guys might be interested in
> getting Unicorn to run under Rubinius since all the currently failing
> parts are still pure Ruby, just not commonly-used Ruby.

Yeah, it sounds like you're hitting some behavior right at the edge of
a bunch of classes. It's pretty likely we haven't yet hit this (no
specs for it). Any of these behaviors though it would be great if you
could write rubyspecs for. That would make it super easy for us to see
your expectations for the behavior and have an isolated test case.
(Continue reading)

Permalink | Reply |
headers
Eric Wong | 23 Nov 2009 19:32

Re: Re: Unicorn on Rubinius?

evanphx <evanwebb <at> gmail.com> wrote:
> Hi Eric!
> 
> Thanks for giving Rubinius a ride on the Unicorn. Sounds like you're
> using a lot of features that we probably haven't yet sussed the bugs
> out of, I'll address them more below.
> 
> On Nov 22, 12:18 am, Eric Wong <normalper... <at> yhbt.net> wrote:
> > Hi all,
> > Since I'm already short on time/resources and unfamiliar with Rubinius
> > internals (or C++), but I thought you guys might be interested in
> > getting Unicorn to run under Rubinius since all the currently failing
> > parts are still pure Ruby, just not commonly-used Ruby.
> 
> Yeah, it sounds like you're hitting some behavior right at the edge of
> a bunch of classes. It's pretty likely we haven't yet hit this (no
> specs for it). Any of these behaviors though it would be great if you
> could write rubyspecs for. That would make it super easy for us to see
> your expectations for the behavior and have an isolated test case.

OK, it might take me a few days to find time to get familiar with
rubyspecs (the spec DSL weirds me out a bit).  I'll be sure to let you
guys know if/when I get around to it.

> > Unicorn does a lot of Unix-only things that are uncommon in most Ruby
> > code:
> >
> > * Working with unlinked Files (empty ones are also shared across
> >   parent+child and we do fchmod() on them).  We also buffer
> >   large uploads to unlinked File objects.  This seems to fail
(Continue reading)

Permalink | Reply |
headers
Evan Phoenix | 23 Nov 2009 19:43
Gravatar

Re: Re: Unicorn on Rubinius?


On Nov 23, 2009, at 10:32 AM, Eric Wong wrote:

> evanphx <evanwebb <at> gmail.com> wrote:
>> Hi Eric!
>> 
>> Thanks for giving Rubinius a ride on the Unicorn. Sounds like you're
>> using a lot of features that we probably haven't yet sussed the bugs
>> out of, I'll address them more below.
>> 
>> On Nov 22, 12:18 am, Eric Wong <normalper... <at> yhbt.net> wrote:
>>> Hi all,
>>> Since I'm already short on time/resources and unfamiliar with Rubinius
>>> internals (or C++), but I thought you guys might be interested in
>>> getting Unicorn to run under Rubinius since all the currently failing
>>> parts are still pure Ruby, just not commonly-used Ruby.
>> 
>> Yeah, it sounds like you're hitting some behavior right at the edge of
>> a bunch of classes. It's pretty likely we haven't yet hit this (no
>> specs for it). Any of these behaviors though it would be great if you
>> could write rubyspecs for. That would make it super easy for us to see
>> your expectations for the behavior and have an isolated test case.
> 
> OK, it might take me a few days to find time to get familiar with
> rubyspecs (the spec DSL weirds me out a bit).  I'll be sure to let you
> guys know if/when I get around to it.
> 
>>> Unicorn does a lot of Unix-only things that are uncommon in most Ruby
>>> code:
>>>
(Continue reading)

Permalink | Reply |
headers
Eric Wong | 23 Nov 2009 19:58

Re: Re: Unicorn on Rubinius?

Evan Phoenix <evan <at> fallingsnow.net> wrote:
> On Nov 23, 2009, at 10:32 AM, Eric Wong wrote:
> > evanphx <evanwebb <at> gmail.com> wrote:
> Ah! We're using the wrong stat for File. Here is File#stat:
> 
>   def stat
>     Stat.new  <at> path
>   end
> 

> IE, it's going to be using stat(), which since the file is unlinked,
> fails. We need to be using fdstat(). Easy fix. Will go in later today.

Thanks!

> >>> * Iterating through ObjectSpace for File objects with the O_APPEND
> >>>   flag and File#sync=true, and then doing File#reopen on them.
> >>>   This seems to fail under test/unit/test_util.rb
> >> 
> >> Zoinks. This sounds like bad news. We don't yet support
> >> ObjectSpace#each_object, and even when we do, this code sounds mighty
> >> dangerous. You could easily see and manipulate File objects that
> >> rubinius kernel is using internally. Why are you doing this?
> > 
> > I was a bit worried at first about it, too, but it's been used pretty
> > heavily already with MRI and it seems to work well.
> 
> The problem is it depends on ObjectSpace#each_object, which we don't
> have implemented. And when we do implement it, it will be a lot slower
> than MRI because of having a moving GC.
(Continue reading)

Permalink | Reply |

Gmane