[#35446] [Ruby 1.9 - Bug #4477][Open] Kernel:exec and backtick (`) don't work for certain system commands — Joachim Wuttke <j.wuttke@...>

10 messages 2011/03/07

[#35476] [Ruby 1.9 - Bug #4489][Open] [PATCH] Encodings with /-(unix|dos|mac)\Z/ — "James M. Lawrence" <quixoticsycophant@...>

20 messages 2011/03/10

[#35552] [Ruby 1.9 - Feature #4523][Open] Kernel#require to return the path of the loaded file — Alex Young <alex@...>

14 messages 2011/03/24

[#35565] [Ruby 1.9 - Feature #4531][Open] [PATCH 0/7] use poll() instead of select() in certain cases — Eric Wong <normalperson@...>

33 messages 2011/03/28

[#35566] [Ruby 1.9 - Feature #4532][Open] [PATCH] add IO#pread and IO#pwrite methods — Eric Wong <normalperson@...>

12 messages 2011/03/28

[#35586] [Ruby 1.9 - Feature #4538][Open] [PATCH (cleanup)] avoid unnecessary select() calls before doing I/O — Eric Wong <normalperson@...>

9 messages 2011/03/29

[ruby-core:35583] Re: [Ruby 1.9 - Feature #4531][Open] [PATCH 0/7] use poll() instead of select() in certain cases

From: KOSAKI Motohiro <kosaki.motohiro@...>
Date: 2011-03-29 12:07:46 UTC
List: ruby-core #35583
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:
>> >
>> > rb_io_poll_fd(int fd, short events, int timeout);
>> >
>> > It is emulated using select() for platforms that we do not support
>> > poll() for. t 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 all
>> > 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:
> ttp://redmine.ruby-lang.org/attachments/1562/io_select_using_poll_test.rb
> I get the following results:
>
> ---- before NOFILE=1024 ---
> max fd: 1024 (results not apparent with <= 1024 max fd)
> last IO: #<IO:fd 1022>
> .050000 1.440000 3.490000 ( .476264)
>
> GC.count: 386
>
> ---- after NOFILE=1024 ---
> max fd: 1024 (results not apparent with <= 1024 max fd)
> last IO: #<IO:fd 1022>
> .430000 0.320000 2.750000 ( .734643)
>
> GC.count: 343
>
> ---- before NOFILE=16384 ---
> max fd: 16384 (results not apparent with <= 1024 max fd)
> last IO: #<IO:fd 16382>
> .610000 5.680000 9.290000 ( .266017)
>
> GC.count: 643
>
> ---- after NOFILE=16384 ---
> max fd: 16384 (results not apparent with <= 1024 max fd)
> last IO: #<IO:fd 16382>
> .970000 0.450000 3.420000 ( .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 use
>> 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. mall 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?

In This Thread