Please see #157 first. At a minimum, it's good background. Further, it's best to do that one first before tackling this one (or they could be done together).
Done reading it? Cool then:
#157 fix would not change any APIs. Here I suggest we do change (some) APIs. Find anything that takes/yields Native_handle. See if it would make sense to take Own_native_handle.
Broadly there are these situations, but there could be more.
1: We already take ownership: arg = Native_handle&& src, meaning src is made .null(), while "we" become responsible for close()ing (not leaking) the FD as appropriate.
This is good for expressiveness and encouraging best practices. Internally to our objects it helps with the mission of #157. Cost: none really; to the user Own_native_handle{fd} is ~same as Native_handle{fd}.
2: We return a new FD: usually via out-arg like Native_handle* tgt. For example Native_handle_receiver::async_receive_native_handle() gets an FD over an IPC channel from the opposing process (conceptually a copy). Make it Own_native_handle* tgt instead.
This helps safety in that we give them a safe auto-closing resource; if they do nothing, then it will not leak. If they want to un-protect it (which is not unlikely; perhaps they have their own system for this), they call: util::disowned_native_handle(*tgt). Cost: pretty much the latter; they'll need to use that liberally, so it's another API to learn albeit a simple one.
--
Main cost: It'll be a breaking change. Various user builds will break upon upgrading to the release with the fix. I'd say worth it.
Priority: no emergency here. Counterpoint: As usual, breaking changes are better earlier rather than later, all else being equal.
Please see #157 first. At a minimum, it's good background. Further, it's best to do that one first before tackling this one (or they could be done together).
Done reading it? Cool then:
#157 fix would not change any APIs. Here I suggest we do change (some) APIs. Find anything that takes/yields Native_handle. See if it would make sense to take Own_native_handle.
Broadly there are these situations, but there could be more.
1: We already take ownership: arg =
Native_handle&& src, meaning src is made .null(), while "we" become responsible forclose()ing (not leaking) the FD as appropriate.This is good for expressiveness and encouraging best practices. Internally to our objects it helps with the mission of #157. Cost: none really; to the user Own_native_handle{fd} is ~same as Native_handle{fd}.
2: We return a new FD: usually via out-arg like
Native_handle* tgt. For example Native_handle_receiver::async_receive_native_handle() gets an FD over an IPC channel from the opposing process (conceptually a copy). Make itOwn_native_handle* tgtinstead.This helps safety in that we give them a safe auto-closing resource; if they do nothing, then it will not leak. If they want to un-protect it (which is not unlikely; perhaps they have their own system for this), they call: util::disowned_native_handle(*tgt). Cost: pretty much the latter; they'll need to use that liberally, so it's another API to learn albeit a simple one.
--
Main cost: It'll be a breaking change. Various user builds will break upon upgrading to the release with the fix. I'd say worth it.
Priority: no emergency here. Counterpoint: As usual, breaking changes are better earlier rather than later, all else being equal.