From: jean.boussier@... Date: 2021-05-14T18:28:26+00:00 Subject: [ruby-core:103854] [Ruby master Feature#17849] Fix Timeout.timeout so that it can be used in threaded Web servers Issue #17849 has been updated by byroot (Jean Boussier). > Do you have an example? I don't have a specific example in mind, but for instance things like: ```ruby module Namespace extend self def clear_something @something, old_something = Something.new, @something @something.clear # if we raise here we might leak or whatever end end ``` The `setup / yield / ensure / clean` pattern is extremely frequent and just fixing this one would be a huge improvement. I just want to make it clear that it won't be sufficient to eliminate all possible woes. > If that's the case I would argue it's a bug of the C extension Sure. But it can similarly be argued (and I heard it before) that a request that doesn't complete in a reasonable time is a bug in the application. But in my opinion web server timeouts are exactly that, a safety net against bugs in the application. That's exactly the kind of cases I want a timeout for. ---------------------------------------- Feature #17849: Fix Timeout.timeout so that it can be used in threaded Web servers https://bugs.ruby-lang.org/issues/17849#change-91975 * Author: duerst (Martin D�rst) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Making this a separate issue from #17837 Eregon (Benoit Daloze) wrote in https://bugs.ruby-lang.org/issues/17837#note-10 (which is about timeouts for regular expressions): > I think fixing Timeout.timeout might be possible. > The main/major issue is it can trigger within `ensure`, right? Is there anything else? > We could automatically mask `Thread#raise` within `ensure` so it only happens after the `ensure` body completes. > And we could still have a larger "hard timeout" if an `ensure` takes way too long (shouldn't happen, but one cannot be sure). > I recall discussing this with @schneems some time ago on Twitter. -- https://bugs.ruby-lang.org/ Unsubscribe: