[catmem] Release Queue Descriptor Even If close() Fails

[ppenna]

Description

This PR is a follow up of #686

Summary of Changes

• Changed close() to release the queue descriptor even if we fail to push_eof().

#686

[iyzhang]

LGTM

[iyzhang]

instead of freeing the queue descriptor, should we eventually have states and the queue should be placed into a CLOSING state, which continues to try to push the EoF?

[ppenna]

instead of freeing the queue descriptor, should we eventually have states and the queue should be placed into a CLOSING state, which continues to try to push the EoF?

Definitely we should have some abstraction for the states of the queue itself, such as we have in Catnap Loop. However, the problem here about continuing try to push EoF is that we are not sure that this is due because the ring buffer is full or the other end has closed the pipe. In the latter case, we don't have a signal mechanism, because a pipe is unidirectional. Any ideias?

[iyzhang]

instead of freeing the queue descriptor, should we eventually have states and the queue should be placed into a CLOSING state, which continues to try to push the EoF?

Definitely we should have some abstraction for the states of the queue itself, such as we have in Catnap Loop. However, the problem here about continuing try to push EoF is that we are not sure that this is due because the ring buffer is full or the other end has closed the pipe. In the latter case, we don't have a signal mechanism, because a pipe is unidirectional. Any ideias?

My thought was that we should at least keep trying to push EoF regardless of whether the other end will read it because it closed the pipe or stopped pulling things out of it.

[ppenna]

instead of freeing the queue descriptor, should we eventually have states and the queue should be placed into a CLOSING state, which continues to try to push the EoF?

Definitely we should have some abstraction for the states of the queue itself, such as we have in Catnap Loop. However, the problem here about continuing try to push EoF is that we are not sure that this is due because the ring buffer is full or the other end has closed the pipe. In the latter case, we don't have a signal mechanism, because a pipe is unidirectional. Any ideias?

My thought was that we should at least keep trying to push EoF regardless of whether the other end will read it because it closed the pipe or stopped pulling things out of it.

Sure, I've opened an issue for this.