-
Notifications
You must be signed in to change notification settings - Fork 580
retain the last file handle even if it's an IO reference #19125
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
base: blead
Are you sure you want to change the base?
Conversation
My gut feeling tells me this will either fix a lot of unexplored format/write problems too. Anyway this is beyond my area of expertise to give a +1 or -1 on the code as shown. |
@tonycoz this seems reasonable, but stalled and in conflict now. Do you want to pick it up? Should I try to resolve conflicts on it? |
I think I left it draft (it's been a while) because of that last problem - IIRC it was I suspect the fix is to increment the reference count when saving, and decrement when restoring, setting That could result in a user visible change of behaviour though, and might need a custom save type. Feel free to pick it up. |
also fixes #17655 |
It's always been possible to extract a reference to the IO SV from a glob, and use that for I/O, but such use would set PL_last_in_gv to a temporary GV which would almost immediately be released, clearing PL_last_in_gv. This would result in reads from $. returning its most recently read value (even from another handle) and modification being ignored, while ${^LAST_FH} would return undef, even though the file handle is still open. To fix this, store the underlying IO object as well as the GV. Retaining the GV lets errors continue to report the GV name where possible, while the IO object means $. and ${^LAST_FH} can still work if the IO object still exists. This does not try to fix the problem where localization can leave PL_last_in_gv (and now PL_last_in_io) pointing at a SV that has been destroyed, the original changes that introduced PL_last_in_gv didn't keep a reference count for the GV, since this would prevent the file being closed automatically when the reference to to the glob went out of scope. Fixes Perl#1420
PL_last_in_gv is a weak pointer to the most recent input handle, if this was localized by localizing $., if the GV it referenced was freed, the popping of the new value from the save stack could set PL_last_in_gv to a now freed, and possible re-used SV slot. To avoid that, keep a reference count to the saved GV when saving it on the save stack. This could possibly delay closing a file but I expect localizing $. is rare, so I don't expect it to be a problem in practice. Fixes Perl#19124
It's always been possible to extract a reference to the IO SV from
a glob, and use that for I/O, but such use would set PL_last_in_gv
to a temporary GV which would almost immediately be released,
clearing PL_last_in_gv.
This would result in reads from
$.
returning its most recently readvalue (even from another handle) and modification being ignored, while
${^LAST_FH}
would return undef, even though the file handle is stillopen.
To fix this, store the underlying IO object as well as the GV.
Retaining the GV lets errors continue to report the GV name where
possible, while the IO object means
$.
and${^LAST_FH}
can still workif the IO object still exists.
This does not try to fix the problem where localization can leave
PL_last_in_gv (and now PL_last_in_io) pointing at a SV that has been
destroyed, the original changes that introduced PL_last_in_gv didn't
keep a reference count for the GV, since this would prevent the file
being close automatically when the reference to to the glob went out
of scope.
Fixes #1420