It's debatable whether this is a bug or not, but I think the current interrupt
handling behavior with IO.copy_stream is fragile and unpredictable, and
inconsistent with IO#read and IO#write.

This is to be consistent with IO#read and IO#write behavior
where rb_io_wait_readable() and rb_io_wait_writable() retry
on interrupt (EAGAIN/ERESTART) instead of returning a short
copy or raising Errno::EINTR.

History

It's debatable whether this is a bug or not, but I think the current interrupt
handling behavior with IO.copy_stream is fragile and unpredictable, and
inconsistent with IO#read and IO#write.

This is to be consistent with IO#read and IO#write behavior
where rb_io_wait_readable() and rb_io_wait_writable() retry
on interrupt (EAGAIN/ERESTART) instead of returning a short
copy or raising Errno::EINTR.

Can I get a response on this soon? I really want this issue resolved
before 1.9.3 because it's inconsistent with existing Ruby read/write
behavior and working around it painful.

Since the experimental function rb_thread_call_with_gvl is not callable
with GVL, nogvl_copy_stream_continue_p is not callable with GVL.
So nogvl_copy_stream_continue_p is not callable from maygvl_* such as
maygvl_copy_stream_wait_read.
I guess maygvl_* functions needs has_gvl parameter to keep GVL status.