From: Charles Oliver Nutter Date: 2012-03-18T07:33:28+09:00 Subject: [ruby-core:43377] Re: [ruby-trunk - Bug #6154][Open] Eliminate extending WaitReadable/Writable at runtime --e89a8fb1eae4392f1c04bb77e9a8 Content-Type: text/plain; charset=UTF-8 I thought about that...it would still be better to add EWOULDBLOCKReadable, etc, than to pay the .extend toll every time. On Mar 17, 2012 10:28 AM, "Tanaka Akira" wrote: > 2012/3/16 Charles Nutter : > > > The nonblocking IO operations started extending WaitReadable or > WaitWritable into the Errno::EAGAIN instance some time during the 1.9 > series. This has a rather high cost, since a singleton class must be > created and the global method cache must be flushed. > > > > The attached patch instead creates two new classes of the following > form, and raises them rather than raising a singleton EAGAIN: > > EWOULDBLOCK is a different from EAGAIN on some platforms. > (HP-UX, for example.) > > I think your patch breaks applications which rescue only EWOULDBLOCK, > on such platforms. > -- > Tanaka Akira > > --e89a8fb1eae4392f1c04bb77e9a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I thought about that...it would still be better to add EWOULDBLOCKReadab= le, etc, than to pay the .extend toll every time.

On Mar 17, 2012 10:28 AM, "Tanaka Akira&quo= t; <akr@fsij.org> wrote:
2012/3/16 Charles Nutter <headius= @headius.com>:

> The nonblocking IO operations started extending WaitReadable or WaitWr= itable into the Errno::EAGAIN instance some time during the 1.9 series. Thi= s has a rather high cost, since a singleton class must be created and the g= lobal method cache must be flushed.
>
> The attached patch instead creates two new classes of the following fo= rm, and raises them rather than raising a singleton EAGAIN:

EWOULDBLOCK is a different from EAGAIN on some platforms.
(HP-UX, for example.)

I think your patch breaks applications which rescue only EWOULDBLOCK,
on such platforms.
--
Tanaka Akira

--e89a8fb1eae4392f1c04bb77e9a8--