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>