From: Francis Cianfrocca <garbagecat10@...>
Date: 2006-05-09T10:51:07+09:00
Subject: Re: Considering Ruby For a Networking Application

------=_Part_47911_18110921.1147139464188
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Your guess about how that Intergraph library happened to get into the distr=
o
makes a lot of sense. They can also roll it back out it they ever decide to=
,
because the core APIs never got changed :-). At the end of the day, however=
,
this convinces me all the more that it was right for us to offer a
higher-level library that wraps up network i/o as much as possible. We wrot=
e
a SIP stack in pure Ruby last year, and it was very painful to get it right
because Ruby's implementation of i/o kept violating expectations.

On 5/8/06, Bill Kelly <billk@cts.com> wrote:
>
> From: "Francis Cianfrocca" <garbagecat10@gmail.com>
> >
> > When you run nonblock_test.rb in Windows, does it ever catch EAGAIN on
> the
> > read thread? (I'm too lazy to track down a Windows box to run it on.)
>
> No; the only exception I ever saw raised was EOFError from the
> readpartial.
>
> I included the EAGAIN handling because the code in
> lib/openssl/buffering.rb is written that way.  But, I was never
> sure it should be necessary, from what I'd seen in the io.c,
> win32/win32.c, and ext/socket/socket.c source.
>
> From casually perusing the source, it appears to me as though
> EAGAIN/EWOULDBLOCK are being handled internally; so I'm unclear
> on why/when one would expect to need to handle them from ruby.
>
> (And, as yet, I've not seen an EAGAIN from readpartial or
> syswrite in my tests on either Linux or Windows... not that my
> tests have been by any means exhaustive... :)
>
>
> Continuing to your next post:
>
> > One more thing, what happens if you run this program on Windows on a
> > network? You have an intra-process localhost connection and the kernel
> may
> > be behaving differently in this case, particularly as regards the buffe=
r
> > usage that would interact with nonblocking i/o.
>
> Good point; I'll try that...
>
> > [...] the wrapper in win32.c. I have to say, it's a strange
> > design choice. To me it would have made more sense to wrap both
> > behind a "setnonblocking" method.
>
> I'd tend to agree, but I think it's partly historical.  The
> nonblocking handling (including the ftctl -> ioctlsocket shunt)
> magically appeared in ruby sometime between 1.8.2 and 1.8.4.
> Previously, there had been discussions on the mailing lists about
> how to address the blocking issues, and suggestions for adding
> a set of nonblock_read(), etc. methods, among other suggestions.
> As I recall, Matz was supportive of seeing a solution to the
> blocking issues, but didn't like any of the as-yet proposed
> method names.  My guess is, some enterprising soul(s) between
> 1.8.2 and 1.8.4 found an acceptable way to make the solution
> happen.... without changing the existing APIs.  :)
>
>
> Regards,
>
> Bill
>
>
>
>

------=_Part_47911_18110921.1147139464188--