[#53944] [ruby-trunk - Bug #8210][Open] Multibyte character interfering with end-line character within a regex — "sawa (Tsuyoshi Sawada)" <sawadatsuyoshi@...>

14 messages 2013/04/03

[#53974] [ruby-trunk - Feature #8215][Open] Support accessing Fiber-locals and backtraces for a Fiber — "halorgium (Tim Carey-Smith)" <ruby-lang-bugs@...>

14 messages 2013/04/03

[#54095] [ruby-trunk - Feature #8237][Open] Logical method chaining via inferred receiver — "wardrop (Tom Wardrop)" <tom@...>

34 messages 2013/04/08

[#54138] [ruby-trunk - Bug #8241][Open] If uri host-part has underscore ( '_' ), 'URI#parse' raise 'URI::InvalidURIError' — "neocoin (Sangmin Ryu)" <neocoin@...>

9 messages 2013/04/09

[#54185] [CommonRuby - Feature #8257][Open] Exception#cause to carry originating exception along with new one — "headius (Charles Nutter)" <headius@...>

43 messages 2013/04/11

[#54196] Encouraging use of CommonRuby — Charles Oliver Nutter <headius@...>

I think we need to do more to encourage the use of the CommonRuby

20 messages 2013/04/11
[#54200] Re: Encouraging use of CommonRuby — Marc-Andre Lafortune <ruby-core-mailing-list@...> 2013/04/11

Hi,

[#54211] Re: Encouraging use of CommonRuby — "NARUSE, Yui" <naruse@...> 2013/04/12

As far as I understand, what is CommonRuby and the process over CommonRuby

[#54207] [CommonRuby - Feature #8258][Open] Dir#escape_glob — "steveklabnik (Steve Klabnik)" <steve@...>

15 messages 2013/04/12

[#54218] [CommonRuby - Feature #8259][Open] Atomic attributes accessors — "funny_falcon (Yura Sokolov)" <funny.falcon@...>

43 messages 2013/04/12

[#54288] [CommonRuby - Feature #8271][Open] Proposal for moving to a more visible, formal process for feature requests — "headius (Charles Nutter)" <headius@...>

15 messages 2013/04/15

[#54333] Requesting Commit Access — Aman Gupta <[email protected]>

Hello ruby-core,

16 messages 2013/04/16

[#54473] [Backport 200 - Backport #8299][Open] Minor error in float parsing — "bobjalex (Bob Alexander)" <bobjalex@...>

27 messages 2013/04/19

[#54532] [ruby-trunk - Bug #8315][Open] mkmf does not include include paths from pkg_config anymore — "Hanmac (Hans Mackowiak)" <hanmac@...>

11 messages 2013/04/23

[#54621] [ruby-trunk - Feature #8339][Open] Introducing Geneartional Garbage Collection for CRuby/MRI — "ko1 (Koichi Sasada)" <redmine@...>

43 messages 2013/04/27
[#54643] [ruby-trunk - Feature #8339] Introducing Geneartional Garbage Collection for CRuby/MRI — "authorNari (Narihiro Nakamura)" <authorNari@...> 2013/04/28

[#54649] Re: [ruby-trunk - Feature #8339] Introducing Geneartional Garbage Collection for CRuby/MRI — SASADA Koichi <ko1@...> 2013/04/28

(2013/04/28 9:23), authorNari (Narihiro Nakamura) wrote:

[#54657] Re: [ruby-trunk - Feature #8339][Open] Introducing Geneartional Garbage Collection for CRuby/MRI — Magnus Holm <judofyr@...> 2013/04/28

On Sat, Apr 27, 2013 at 8:19 PM, ko1 (Koichi Sasada)

[#54665] [ruby-trunk - Bug #8344][Open] Status of Psych and Syck — "Eregon (Benoit Daloze)" <redmine@...>

18 messages 2013/04/28

[ruby-core:54376] Re: [ruby-trunk - Bug #8208] Raise cached exceptions for nonblocking IO to avoid allocation/stack-copying costs

From: Charles Nutter <headius@...>
Date: 2013-04-17 02:31:21 UTC
List: ruby-core #54376
On Apr 16, 2013, at 8:42 PM, Eric Wong <[email protected]> wrote:
> How does this compare to an implementation which returns symbols
> like :wait_*able instead of raising exceptions?

It will be more expensive, but mostly because exception-handling has a =
fair amount of overhead even with a cached exception object. I suggest =
this mostly because it may be considered less invasive than adding new =
APIs.

>> The benefit of this change would be that nonblocking IO has zero
>> wasted overhead. The down side would be that the exceptions raised do
>> not have a useful backtrace unless debug or verbose.
>=20
> Exceptions for nonblocking I/O still makes --debug too noisy.

Indeed!

> I still think it's better to push for an exception-less API for common
> errors.  EAGAIN/EINPROGRESS/EWOULDBLOCK are far too common (and not
> reasonably avoidable) to be considered exceptions.

Agreed=85but that hasn't happened yet. I'm hedging my bets :-)

Which issue is tracking an exceptionless nonblocking API? Maybe we can =
nudge it forward.

- Charlie=

In This Thread