0

I am using a Python module that has a function which sends an http request. This function doesn't implement a timeout, and in certain circumstances the request ends up blocking forever and my program cannot proceed. Editing the code of the module is not an option, and I must use the above-mentioned function. What's a good design pattern to prevent getting stuck in the (rare) cases when the function blocks forever? When this occurs, I would like to "kill" the function after a certain time and retry.

ReasonMeThis
  • 203
  • 1
  • 7
  • What module are you using? Wouldn't it be worthwhile to rely on an implementation that does this out of the box, instead of re-inventing the wheel? And then: please turn to the [help] to remind yourself how to ask here. As in: you are expected to research before posting a question. So: make your favorite search engine your first stop : https://stackoverflow.com/questions/492519/timeout-on-a-function-call – GhostCat Sep 27 '22 at 07:34
  • Just to be clear... You want different behaviour without changing the code? – DarkKnight Sep 27 '22 at 07:34
  • Does this answer your question? [Timeout on a function call](https://stackoverflow.com/questions/492519/timeout-on-a-function-call) – GhostCat Sep 27 '22 at 07:34
  • 1
    Implement a new function, use threading and kill the thread upon timeout. You call this a "wrapper" or "adapter pattern". You have one interface (blocking) and convert it into another interface (non-blocking). – Thomas Weller Sep 27 '22 at 07:35
  • Please add an example of the code you use so that we can better understand your problem. You could, for instance, use asyncio wait_for to create an ultimate timeout. – Cow Sep 27 '22 at 07:35
  • 1
    And side note: whoever upvoted this question ... it really isn't upvote worthy. It lacks code and prior research. A fuzzy description of requirements isn't a good question. – GhostCat Sep 27 '22 at 07:36
  • @GhostCat to respond to your critique, the relevant similar questions I found are from 7-11 years ago. Since there have been many advances in concurrency/async since then, it is not safe to assume that the answers from back then represent what would be the best practice now in 2022. – ReasonMeThis Sep 27 '22 at 07:59
  • @ReasonMeThis You have no code, so it's impossible to answer your question without guessing or writing something opinion based, which is off topic. – Cow Sep 27 '22 at 08:02
  • The duplicate I linked to gives multiple approaches. Plenty of them rely on built modules/functionality. Shouldn't you first check if those things ... simply still work for you? And when they do not, you should at least link to what you tried yourself. Because there is a good chance that you would first get very similar answers. You see: no research can't be distinguished from "did research, but not mention it at all". – GhostCat Sep 27 '22 at 08:10

0 Answers0