1. 21
  1.  

  2. 2

    Is the API at fault or the implementation?

    Perhaps each block guarded by the timeout could have an associated flag allocated on entry?

    The block could set the flag on exit. The sleeping timeout thread could check the flag when the timeout expires. If it is set then it should not raise the exception on the block and instead just cleanup+destroy the flag. If the flag is clear then raise the exception.

    There’s a clear race there with an ordinary flag variable, but perhaps think a simple mutex around it would suffice?

    Have I missed some problem, or is there another reason the other languages with a similar feature have deprecated it?

    1. 9

      The idea itself of letting a thread kill another thread at anytime is bad. Some details here: http://www.jerf.org/iri/post/2930#no_async_exceptions

      1. 2

        I agree the general case is bad, i was proposing limiting the dynamic scope in which the exception might be raised to just the intended block. Is tbere also a problem there?

        1. 2

          There is still a problem. The timeout exception is asynchronous and can happen any time during the execution of the block “guarded by the timeout”. If the block calls a function that contains an ensure clause, for example used to release a resource (a file handle, a lock, etc.), and the timeout exception is raised in the middle of the ensure clause, then the resource will not be correctly released, and you have a problem.

          1. 1

            Thanks, that’s a good problem statement.