On Sun, Jun 5, 2016 at 1:26 PM, Eric Wong <normalperson / yhbt.net> 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
<https://docs.oracle.com/javase/tutorial/essential/concurrency/interrupt.html>
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.
(supressed text/html)
Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>