-
Notifications
You must be signed in to change notification settings - Fork 5.4k
Hide most of the implementation of struct rb_io
.
#6511
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
4cfeb71
to
ab41c3b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
@eregon do you know if this is in violation of any C specification or potentially creates undefined behaviour for us? |
fcdfafa
to
55a028c
Compare
I don't know. |
1c0cc42
to
563ea1d
Compare
This looks good and makes sense to me! |
int len; | ||
|
||
/** Designed capacity of the buffer. */ | ||
int capa; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious as why unsigned int here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, it's odd. But not part of my design, it's what's copied.
563ea1d
to
e3b529d
Compare
cfcec68
to
8823f74
Compare
882a084
to
cbe5d12
Compare
a4551b3
to
ee613f8
Compare
I had thought that "slavepty:$slavename" was a better name, but there are tests for the current name so somebody is probably depending on the current behaviour.
FMODE_PREP I believe refers to the concept of a "pre-prepared" file, but FMODE_EXTERNAL is clearer about what the file descriptor represents and aligns with language in the IO::Buffer module.
If FMODE_EXTERNAL is not set, then it's guaranteed that Ruby will be responsible for closing your file, eventually, if you pass it to rb_io_open_descriptor, even if it raises an exception.
ee613f8
to
74b830b
Compare
@KJTsanaktsidis if you have time, do you mind reviewing the last set of commits? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, just a couple of teeny tiny issues
@@ -70,7 +70,7 @@ const union { | |||
RUBY_FMODE_NOREVLOOKUP = 0x00000100, | |||
RUBY_FMODE_TRUNC = FMODE_TRUNC, | |||
RUBY_FMODE_TEXTMODE = FMODE_TEXTMODE, | |||
RUBY_FMODE_PREP = 0x00010000, | |||
RUBY_FMODE_EXTERNAL = 0x00010000, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wrote this, but since FMODE_EXTERNAL
is exported now, this should readRUBY_FMODE_EXTERNAL = FMODE_EXTERNAL
rather than duplicating its definition.
VALUE io = io_alloc(klass); | ||
VALUE path_value = Qnil; | ||
if (path) { | ||
path_value = rb_obj_freeze(rb_str_new_cstr(path)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suuuuper nitpicky, but - if rb_str_new_cstr
raises, this will then leak the file descriptor (because rb_io_open_descriptor
won't have been called).
I also just realised the usages of rb_io_open_descriptor
I added in pty.c
have the same problem - they open a file, then construct a path (in a way that can raise), and then call rb_io_open_descriptor
with said path.
I wonder if the API might be safer if we stop rb_io_open_descriptor
from taking a path at all, and instead expose a rb_io_set_path
? That way the path can be constructed after the FD is safely put under the management of the GC.
(or, we might decide we just don't care - probably the only way these string allocations can raise is out-of-memory conditions or very silly tracepoints?)
This reverts commit 18e55fc. fix [Bug #19704] https://bugs.ruby-lang.org/issues/19704 This breaks compatibility for extension libraries. Such changes need a discussion.
https://bugs.ruby-lang.org/issues/19057