[Mongrel-development] Review of Code for 1.9
luislavena at gmail.com
Thu Dec 27 07:01:10 EST 2007
On Dec 27, 2007 1:07 AM, Filipe <filipe at icewall.org> wrote:
> Thanks for the links :)
> Well, one important note from ko1 in one of those links:
> (3') select() system call can be interrupted with pthread_kill(). But
> on cygwin system, pthread_kill() doesn't work well. oops.
> If we use the code that I sent, we may have problems wih cygwin. BUT:
> 1) (I hope that) no sane human will run a production server in cygwin
> 2) This problem would only happen in cygwin when stopping mongrel, so it's not
> really one of the biggest problems in the world.
Yeah, cygwin is not a good alternative, even that some editors (like
E) encourage users to use a cygwin environment to "mimic" linux.
I give support for mongrel on "mswin32" platform, not cygwin (hey, I
even plan to support mingw when get it working right).
> Also, besides using the code already sent, we could call accept_nonblock()
> and then get into a loop calling select in the socket for a limited time and then
> check a variable to exit. Something like this:
> serv = TCPServer.new('127.0.0.1', 3000)
> sock = serv.accept_nonblock
> rescue Errno::EAGAIN, Errno::ECONNABORTED, Errno::EPROTO, Errno::EINTR
> #executes select for 3 seconds before try our exit variable
> IO.select([serv], nil, nil, 3)
> return if die
> This way we just set @acceptor.die = true, join it and wait. How about it?
That could work, but we will still be attached/limited/sticked/busted
one developer started a thread at ruby-core listing the 'evented'
frameworks available, how bad they behave and listing part of the
problems they currently present.
Also, describe that something could be done in the Fibers arena to
workaround this, thus removing the need for external C code:
But still, don't have free time to look deep into this (damn work, I
hate it, need to code some usb driver for windows by tonight).
For the time being, I suggest we take stable 1.1 and:
force required_ruby_version '<1.9.0'
release a new gems for it (I'll do the same for the pre-build binary).
I'm working on getting mongrel_service fixed (removing win32-service
dependency since latest version broke API and affect GemPlugin
I'll add the same forced ruby_version to it.
I don't ask for volunteers here, but if someone can, it's really welcome :-D
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
More information about the Mongrel-development