Thread#raise, Thread#kill, and timeout.rb are unsafe

[Tanaka Akira]

Now, the question with IO and asynchronous exceptions in Ruby is
whether there is a good way to report a partial result?

I think defining the partial results causes, ultimately,
event driven architecture.

The partial result is similar to a continuation.

For syswrite, it is number of bytes wrote. It can be used
to resume syswrite.

If IO#gets returns a partial result on an interrupt, it
should be usable to resume IO#gets. It may contain the
bytes read. If the IO converts character code, it may
contain characters converted, a state of character code
conversion engine and the bytes not converted yet.

If http request reading procedure returns partial result on
an interrupt, it should be usable to resume the procedure.
It contains a state of http request parser. If the parser
is recursive decent, it contains the stack. It is the
continuation.

So defining the partial result of a complex I/O operation
such as http request reading is translating continuation to
some data structure. It is done by an event driven
architecture.

If a program is not event driven, I think that defining the
partial results for complex I/O operations is too tedious.

 

[Tanaka Akira]

This seems sensible to me, though it would be nice to also have
an alternate way to handle POSIX signals that didn't involve
interruption.

Thread.delay_interrupt(klass) { ... } is intended for that.

Hm. It may need to take "SIGTERM", etc. because Ruby has no
exception class corresponding to single signal, SIGTERM,
etc.

 

[Tanaka Akira]

I think I agree. However, that still leaves us with timeouts, which
are sometimes done for operations that will be retried in the future,
so data loss is not acceptable there.

For net/http, data loss is not big problem because
timeouted request is not resumed. The timeout terminates
the http request.

I'm not sure your assumption. If an operation will be
resumed later, why the operation needs timeout? What a task
should be done between the timeout and the resuming? Why
the task should not be done in another thread?

Won't we also need to augment the existing stdlib APIs to allow the
specification of timeouts for any blocking operations that can't
already be done with non-blocking and select?

It is reasonable, I think.

 

[Roger Pack]

Basically you need to have the equivalent of this:

Thread.uninterruptable do
begin
Thread.interruptable do
# ...
end
rescue
# ...
ensure
# ...
end
end

Yeah that would be work. That or, as one poster put it, only use
exceptions to kill, not to raise (to snuff out the non-determinism and
force users to use queues). Both of those would work.
Good luck.
-R