[ruby-core:27406] Re: [ANN] openssl-nonblock 0.2.1: moving towards compatibility with Ruby 1.9.2

On Dec 15, 2009, at 11:04 PM, Tony Arcieri wrote:

> I implement the following methods as part of OpenSSL::SSL::SSLSocket:
> 	=95 connect_nonblock: connect to an SSL server
> 	=95 accept_nonblock: accept an SSL connection
> 	=95 read_nonblock(length): read up to the given length, but =
don=92t block
> 	=95 write_nonblock(data): write as much of the given data as =
possible =20
> without blocking
> I raise the following exceptions:
>
> 	=95 IO::WaitReadable: this means OpenSSL needs to read more data =
to =20
> complete the
> given request. You should wait until the underlying IO object becomes
> readable again before retrying the request.
> 	=95 IO::WaitWritable similar to above, except OpenSSL is trying =
to =20
> write data to
> the IO object, and the IO object is not presently writable. You =20
> should wait
> until the object becomes writable again before retrying the request.
> Does this sound like I am properly matching what is available in =20
> Ruby 1.9.2?

I compared the behavior of openssl-nonblock to Ruby 1.9.2 (but not =20
exhaustively), and the main issue I saw was the use of a different =20
underlying exception object.  Ruby 1.9.2 raises an SSLError while =20
openssl-nonblock raises its own ReadAgain/WriteAgain object extended =20
with IO::WaitReadable/IO::WaitWritable.  Now, if all one cares about =20
is being notified that the operation would block (that is, if one is =20
just rescuing WaitReadable/WaitWritable), then openssl-nonblock and =20
Ruby 1.9.2 are indistinguishable.  However, it's possible for someone =20=

to rescue SSLError directly, and then the difference shows up.

I tried creating a patch to make openssl-nonblock use SSLError just =20
like Ruby 1.9.2, but that seemed like it was going to be more work =20
than I expected (partly because somethings are defined static inside =20
the OpenSSL extension).

I'm not sure how important this difference is in practice, because it =20=

mainly affects a narrow use case--running a program written for Ruby =20
1.9.2 or later on an older Ruby (that is, backporting features).  =20
That's a different use case than supporting nonblocking OpenSSL I/O on =20=

older Ruby versions in a *forward* compatible manner (obviously, for =20
portability, such code should not rescue ReadAgain/WriteAgain, only =20
WaitReadable/WaitWritable).

  --Young