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 <[email protected]> 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. > > 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. This does not happen on MRI? Child processes to share file descriptors (and thusly unix kernel file objects) with the parent, so this is how I'd expect it to work. What behavior are you expecting? > > * 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? > > * Signal handlers, I keep them short and process them later in > the main event loops. test_signals.rb seems to get bogged > down and weird, and test_exec.rb is basically shell script > written in Ruby. We haven't pushed hard on Signal handlers, I'll take a look at this. > > * {TCP,UNIX}Server socket objects may be duplicated as bare Socket > objects in the IO_PURGATORY array. We can inherit non-FD_CLOEXEC > file descriptors from our parent, and first create an intermediate > bare Socket object before finally "casting" it into a TCPServer > or UNIXServer socket object. We keep the original Socket in > IO_PURGATORY to prevent the GC from nuking the underlying > descriptor. Not sure how much of a problem this is... This should be fine, though if you're duping a Socket, perhaps there is a bug there. > > A good chunk of the so-called "unit" tests are actually messy+ugly > integration tests, and they'll fork off all over the place; even run > curl or dd. > > I basically do not trust my own knowledge/use of Ruby, especially > after what 1.9 did with encodings; so some tests use curl/dd to write > data to sockets. > > Some parts definitely over-test some things, but the tests still run > pretty quickly because I can run them in parallel with GNU make[1]. > > If you want, please grab the latest code off > git://git.bogomips.org/unicorn and poke around it yourselves > > There's the HACKING document in there and I've tried to ensure the weird > parts lib/unicorn.rb and lib/unicorn/util.rb are well-commented. Please > let me know if you have any questions or need clarification for it, I'll > be glad to answer. Just don't ask me to look at and debug C++ :) I'm > very glad your Capi seems to work well and all the HTTP parser tests > pass. Sounds like we should be able to get this sorted out, just need a bit more info on the questions I've asked above. > > [1] - I'm not afraid to admit I *like* programming with gmake :> > > -- > Eric Wong -- --- !ruby/object:MailingList name: rubinius-dev view: http://groups.google.com/group/rubinius-dev?hl=en post: [email protected] unsubscribe: [email protected]
