[#40602] [ruby-trunk - Bug #5532][Open] Compile problem for bigdecimal on cygwin — Martin Dürst <duerst@...>

14 messages 2011/11/01

[#40617] [ruby-trunk - Feature #5534][Open] Redefine Range class and introduce RelativeNumeric and RelativeRange — Alexey Muranov <muranov@...>

17 messages 2011/11/01

[#40646] [ruby-trunk - Bug #5541][Open] Better configure error message when llvm-gcc is the default compiler — Eric Hodel <drbrain@...7.net>

10 messages 2011/11/01

[#40648] [ruby-trunk - Feature #5543][Open] rb_thread_blocking_region() API is poorly designed — Christopher Huff <cjameshuff@...>

14 messages 2011/11/01

[#40684] [ruby-trunk - Feature #5555][Open] rename #include? to #includes? — Alexey Muranov <muranov@...>

20 messages 2011/11/02

[#40688] [ruby-trunk - Bug #5556][Open] SIGHUP no longer ignored when sent to process group from a subprocess — Brian Ford <brixen@...>

12 messages 2011/11/02

[#40706] [ruby-trunk - Feature #5562][Open] Improvement of Windows IO performance — Hiroshi Shirosaki <h.shirosaki@...>

39 messages 2011/11/03

[#40737] [ruby-trunk - Bug #5570][Open] Encoding of environment variables on Windows — Nikolai Weibull <now@...>

11 messages 2011/11/04

[#40748] Proposal for sustainable branch maintenance — "Yuki Sonoda (Yugui)" <yugui@...>

-----BEGIN PGP SIGNED MESSAGE-----

14 messages 2011/11/05

[#40770] [ruby-trunk - Feature #5578][Open] Embedded YAML for Ruby 2.0 — Thomas Sawyer <transfire@...>

17 messages 2011/11/06

[#40806] [ruby-trunk - Feature #5583][Open] Optionally typing — Yasushi ANDO <andyjpn@...>

21 messages 2011/11/07

[#40824] [ruby-trunk - Feature #5588][Open] add negation flag (v) to Regexp — Suraj Kurapati <sunaku@...>

38 messages 2011/11/08

[#40865] IO.copy_stream creates files with restrictive permissions — Eric Wong <normalperson@...>

I'm not sure if this is a bug or intended as spec.

16 messages 2011/11/09
[#41151] Re: IO.copy_stream creates files with restrictive permissions — Tanaka Akira <akr@...> 2011/11/19

2011/11/9 Eric Wong <normalperson@yhbt.net>:

[#41166] Re: IO.copy_stream creates files with restrictive permissions — KOSAKI Motohiro <kosaki.motohiro@...> 2011/11/20

>> I noticed when a file name argument is passed to the IO.copy_stream, the

[#41168] Re: IO.copy_stream creates files with restrictive permissions — Clifford Heath <clifford.heath@...> 2011/11/20

On 20/11/2011, at 5:09 PM, KOSAKI Motohiro wrote:

[#41176] Re: IO.copy_stream creates files with restrictive permissions — Tanaka Akira <akr@...> 2011/11/21

2011/11/20 Clifford Heath <clifford.heath@gmail.com>:

[#41180] Re: IO.copy_stream creates files with restrictive permissions — KOSAKI Motohiro <kosaki.motohiro@...> 2011/11/21

>> I think documentation is the wrong answer. The security defects are not caused

[#40908] [ruby-trunk - Feature #5607][Open] Inconsistent reaction in Range of String — Yen-Nan Lin <redmine@...>

15 messages 2011/11/10

[#40941] [ruby-trunk - Feature #5617][Open] Allow install RubyGems into dediceted directory — Vit Ondruch <v.ondruch@...>

22 messages 2011/11/11

[#40951] [Backport93 - Backport #5621][Open] Please backport thread-safe autoloading patch — Mike Perham <mperham@...>

25 messages 2011/11/12
[#40971] [Backport93 - Backport #5621] Please backport thread-safe autoloading patch — Mike Perham <mperham@...> 2011/11/12

[#40972] Re: [Backport93 - Backport #5621] Please backport thread-safe autoloading patch — Yehuda Katz <wycats@...> 2011/11/12

Unfortunately ruby-head has a deadlock in one of my go-to scenarios for

[#40976] Re: [Backport93 - Backport #5621] Please backport thread-safe autoloading patch — Hiroshi Nakamura <nahi@...> 2011/11/13

-----BEGIN PGP SIGNED MESSAGE-----

[#41128] Re: [Backport93 - Backport #5621] Please backport thread-safe autoloading patch — Charles Oliver Nutter <headius@...> 2011/11/18

On Sat, Nov 12, 2011 at 7:24 PM, Hiroshi Nakamura <nahi@ruby-lang.org> wrote:

[#41129] Re: [Backport93 - Backport #5621] Please backport thread-safe autoloading patch — Hiroshi Nakamura <nahi@...> 2011/11/18

-----BEGIN PGP SIGNED MESSAGE-----

[#41142] Re: [Backport93 - Backport #5621] Please backport thread-safe autoloading patch — Charles Oliver Nutter <headius@...> 2011/11/18

On Fri, Nov 18, 2011 at 12:15 AM, Hiroshi Nakamura <nahi@ruby-lang.org> wrote:

[#40982] [ruby-trunk - Bug #5625][Open] Remove profanity and pejoratives — Andrew Grimm <andrew.j.grimm@...>

30 messages 2011/11/13

[#41004] [ruby-trunk - Feature #5628][Open] Module#basename — Thomas Sawyer <transfire@...>

18 messages 2011/11/14

[#41024] [ruby-trunk - Feature #5632][Open] Attempt to open included class shades it instead. — Boris Stitnicky <boris@...>

12 messages 2011/11/14

[#41025] Proposal to add new methods: positive? negative? natural? — JosFrancisco Calvo Moreno <josefranciscocalvo@...>

Hi all!

11 messages 2011/11/14
[#41027] Re: Proposal to add new methods: positive? negative? natural? — Jeremy Evans <code@...> 2011/11/14

On 11/15 12:58, Jos? Francisco Calvo Moreno wrote:

[#41031] Re: Proposal to add new methods: positive? negative? natural? — JosFrancisco Calvo Moreno <josefranciscocalvo@...> 2011/11/14

Hi Jeremy,

[#41038] [ruby-trunk - Bug #5634][Open] yield and binding — Thomas Sawyer <transfire@...>

17 messages 2011/11/14

[#41086] [ruby-trunk - Feature #5644][Open] add Enumerable#exclude? antonym — Suraj Kurapati <sunaku@...>

14 messages 2011/11/17

[#41175] [ruby-trunk - Feature #5654][Open] Introduce global lock to avoid concurrent require — Hiroshi Nakamura <nakahiro@...>

12 messages 2011/11/21

[#41200] [ruby-trunk - Bug #5659][Open] bug releasing a gem created with rails 3.1 — Vinicius Gati <viniciusgati@...>

14 messages 2011/11/22

[#41212] [ruby-trunk - Feature #5662][Open] inject-accumulate, or Haskell's mapAccum* — Edvard Majakari <edvard.majakari@...>

12 messages 2011/11/22

[#41213] [ruby-trunk - Bug #5663][Open] Combined map/select method — Yehuda Katz <wycats@...>

62 messages 2011/11/22

[#41317] [ruby-trunk - Bug #5676][Open] miniruby linking error: undefined reference to ___stack_chk_guard — Martin Dürst <duerst@...>

10 messages 2011/11/27

[#41404] [ruby-trunk - Bug #5690][Open] Module#qualified_const_get — Yehuda Katz <wycats@...>

31 messages 2011/11/30

[ruby-core:41350] Re: [ruby-trunk - Feature #5677][Open] IO C API

From: Eric Wong <normalperson@...>
Date: 2011-11-28 05:03:22 UTC
List: ruby-core #41350
Martin Bosslet <Martin.Bosslet@googlemail.com> wrote:
> This is related to the proposal in [ruby-core:41321][1].
> 
> I'd like to take advantage of streaming IO in an extension I am
> working on. The problem I'm having is that I don't want to call
> IO#read on the rb_funcall level because that would kill the
> performance due to wrapping the bytes into Ruby objects back and
> forth again.

Is starting with Ruby String objects (with binary encoding) and then
having read(2)/write(2) hit RSTRING_PTR not possible?

> I saw two solutions to my problem:
> 
> 1. Duplicating the file descriptor to obtain a pure FILE*
> like it is done in ext/openssl/ossl_bio.c[2] and continue
> working on the raw FILE*.

That may be from the old 1.8 days when all IO objects wrapped FILE *.
It might be better to use BIO_new_fd() nowadays instead since 1.9
generally prefers bare file descriptors (for all fd > 2).

> 2. Since I really only need to read and write on the stream,
> I was looking for public Ruby C API that would support me
> in the process, and I found
> 
>  - ssize_t rb_io_bufwrite(VALUE io, const void *buf, size_t size)
>  - ssize_t rb_io_bufread(VALUE io, void *buf, size_t size)

Is userspace buffering really necessary in your case?

If you're working with sockets/pipes, I would reckon not (Ruby already
defaults to IO#sync=false on sockets/pipes when writing).  If you're
reading (and probably parsing), you would need to do your own read
buffering anyways, no?

> I think both cases are valid use cases, 1. is likely necessary
> if there is the need to pass a FILE* on to an external C library,

It's not easily possible to share userspace buffers in FILE * with
userspace buffers in rb_io_t.  Userspace buffering is pretty miserable
and error-prone whenever/wherever IPC is concerned.

> 2. is for cases like mine where there is the need to operate
> on raw C data types for performance reasons.

It depends on what you're doing, but if performance is a concern you
should try to work on largish chunks off the file descriptor and
skip the userspace buffering stages.  Userspace buffering can improve
performance by reducing syscalls, but it can also double the memory
bandwidth required to do things.

In This Thread