[Mongrel-development] Review of Code for 1.9

[Luis Lavena]

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)
> begin
>    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
>    retry
> end
>
> 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
to Threads.

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:

http://groups.google.com/group/ruby-core-google/browse_thread/thread/fbf8bae96b00d1f5

[ruby-core:14497]
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/14497

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

Volunteers? :-D

I'm working on getting mongrel_service fixed (removing win32-service
dependency since latest version broke API and affect GemPlugin
namespace)
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

Regards,
-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams