2011/3/29 Eric Wong <normalperson / yhbt.net>:
> KOSAKI Motohiro <kosaki.motohiro / gmail.com> wrote:
>> > ref: [ruby-core:35527]
>> >
>> > This adds a new C API function with the following prototype:
>> >
>> > =A0 rb_io_poll_fd(int fd, short events, int timeout);
>> >
>> > It is emulated using select() for platforms that we do not support
>> > poll() for. =A0It is much easier to use than rb_thread_select() and
>> > rb_thread_fd_select() for the common case in C extensions[1].
>> >
>> > For Linux (and eventually any other platforms where poll() works for a=
ll
>> > select()-able files), we actually implement rb_io_poll_fd() using the
>> > poll() system call which means it is faster for high numbered file
>> > descriptors and does not put malloc pressure on the garbage collector.
>>
>> Meta review comment. All performance patches should have mesured
>> performance number.
>
> Based on a contrived test case:
> =A0http://redmine.ruby-lang.org/attachments/1562/io_select_using_poll_tes=
t.rb
> I get the following results:
>
> ---- before NOFILE=3D1024 ---
> max fd: 1024 (results not apparent with <=3D 1024 max fd)
> last IO: #<IO:fd 1022>
> =A02.050000 =A0 1.440000 =A0 3.490000 ( =A03.476264)
>
> GC.count: 386
>
> ---- after NOFILE=3D1024 ---
> max fd: 1024 (results not apparent with <=3D 1024 max fd)
> last IO: #<IO:fd 1022>
> =A02.430000 =A0 0.320000 =A0 2.750000 ( =A02.734643)
>
> GC.count: 343
>
> ---- before NOFILE=3D16384 ---
> max fd: 16384 (results not apparent with <=3D 1024 max fd)
> last IO: #<IO:fd 16382>
> =A03.610000 =A0 5.680000 =A0 9.290000 ( =A09.266017)
>
> GC.count: 643
>
> ---- after NOFILE=3D16384 ---
> max fd: 16384 (results not apparent with <=3D 1024 max fd)
> last IO: #<IO:fd 16382>
> =A02.970000 =A0 0.450000 =A0 3.420000 ( =A03.415426)
>
> GC.count: 394
>
> I don't have real world results/test case but I think small bits
> like this count for the future.

Never mind. this result is successful to persuade me. :)
I'll review whole series and commit them if I don't have no issue.


>> And, if you really want to care C10K scalability issue, why don't you us=
e
>> epoll?
>
> I assume you mean Ruby programming in general and not making MRI itself
> use epoll().
>
> I find synchronous programming easier especially when dealing with
> existing libraries (I use Ruby to make programming life easier :)
>
> For me, thousands of native threads (NPTL + 64-bit) often makes more
> sense than epoll() + non-blocking I/O.
>
> Concurrent connections isn't always an issue, either, but also sometimes
> have many open file handles to support other tasks[1].

OK. I have no objection.


> I mainly think select() is a horrible interface and having extension
> authors to deal with HAVE_RB_FD_INIT and remembering rb_fd_term() is
> dangerous. =A0Small bits of pressure from Rubyists can hopefully steer
> other OSes towards better poll() support.

I'm sorry. I haven't catch this. can you please explain more detail?