Open disruptek opened 5 years ago
A lesser solution might be to make registerProcess not be {.discardable.}.
That is the solution, of course now it'll break code... So silly that registerProcess
is discardable.
So the next best solution is to make the close
for Selector throw an error when it has some file descriptors that haven't been closed. But... that also has the potential to break code...
I think we're left with only one option: deprecate registerProcess
and introduce a new proc that isn't discardable
.
dom96, what is wrong with making close()
cleanup any un-unregistered resources?
One problem I can think of is: what if you have two selectors and register the same FDs into both?
Why would that be a problem?
because closing one of the selectors will close FDs that belong to another selector
Nah.
As discussed on IRC, this is a problem and I think we should solve this by deprecating registerProcess
and introducing a non-discardable version of it with a new name.
Appears to be an identical problem with registerTimer
...
I made a selector like this:
This is leaking the file descriptor returned by
registerProcess
.one solution
I would like
close
tounregister
any extant event listeners.another solution
A lesser solution might be to make
registerProcess
not be{.discardable.}
.Thanks to @zevv for help debugging.