From: Mohamed Hafez Date: 2016-06-05T17:37:45-07:00 Subject: [ruby-core:75849] Re: [Ruby trunk Feature#12435] Using connect_nonblock to open TCP connections in Net::HTTP#connect --===============0764147334== Content-Type: multipart/alternative; boundary=001a1142c8dc01ddf5053491487b --001a1142c8dc01ddf5053491487b Content-Type: text/plain; charset=UTF-8 On Sun, Jun 5, 2016 at 1:26 PM, Eric Wong wrote: > > So, the better option may be to fix Timeout.timeout somehow; > possibly exposing a C API which works safely with the VM and > knows only to interrupt at pre-defined "timeout points" > (similar to cancellation points in pthreads, perhaps using > an existing timer_thread). > > That would be great, I'd argue that having something like Java's interrupt system would be the best long term approach since the way timeouts are done now are inherently unsafe... though they are handy for quick-and-dirty scripts, maybe there could be be a separate Timeout.safe_interrupt method along side it or something Not sure if its worth the trouble, but for now perhaps we could keep the connect_nonblock code and then just have the Timeout.timeout around the Socket.sockaddr_in, with an option to turn that off for people who are using this method on a large scale and want to avoid issues with Timeout.timeout, I'm currently running my own patch doing just that. Socket.sockaddr_in might take a long time in some cases, but would it hang forever if there wasn't a timeout around it? (It doesn't seem too with JRuby at least). Although I agree with @nurse that having these be options for TCPSocket.open would probably be a cleaner and more easily reusable solution. --001a1142c8dc01ddf5053491487b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sun, Jun 5, 2016 at 1:26 PM, Eric Wong <normalperson@yhbt.net&g= t; wrote:

So, the better option may be to fix Timeout.timeout somehow;
possibly exposing a C API which works safely with the VM and
knows only to interrupt at pre-defined "timeout points"
(similar to cancellation points in pthreads, perhaps using
an existing timer_thread).

That wou= ld be great, I'd argue that having something like Java= 9;s interrupt system would be the best long term approach since the way= timeouts are done now are inherently unsafe... though they are handy for q= uick-and-dirty scripts, maybe there could be be a separate Timeout.safe_int= errupt method along side it or something

Not sure = if its worth the trouble, but for now perhaps we could keep the connect_non= block code and then just have the Timeout.timeout around the=C2=A0Socket.sockaddr_in, with an option to turn that off= for people who are using this method on a large scale and want to avoid is= sues with Timeout.timeout, I'm currently running my own patch doing jus= t that.=C2=A0Socket.sockaddr_in mig= ht take a long time in some cases, but would it hang forever if there wasn&= #39;t a timeout around it? (It doesn't seem too with JRuby at least).= =C2=A0Although I agree with @nurse = that having these be options for=C2=A0TCPSocket.open would probably be a cleaner and more easily reusable solu= tion.

=

--001a1142c8dc01ddf5053491487b-- --===============0764147334== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Unsubscribe: --===============0764147334==--