Queue drop Behavior and Clean-Up Actions

[LeStarch]

Ports that have drop behavior on overflow can cause a resource leak when arguments require clean-up. Consider the case of passing an Fw::Buffer through a port. In most cases, Fw::Buffer must be returned to the source (e.g. returning to the buffer manager buffer pool). If a port overflows, that Fw::Buffer will be dropped and it would not be returned to the buffer manager. This is a resource leak.

There is at-least one possible solutions, and a work-around.

Work-Around

Projects sending critical resources through a port call where these resources require clean-up actions should not use drop on the queues. To maintain similar behavior, users may implement a sync or guarded port, and implement their own queue cleaning-up on overflow.

Solution: Add <port>_dropHandler To Auto-code

Autocode could be improved to add a <port>_dropHandler function for ports with drop behavior. This would be a synchronous function call with the same arguments as the port. The default implementation would be a no-op but users could override the behavior.

Example

// Component HPP:
void bufferPort_dropHander(NATIVE_INT_TYPE index, Fw::Buffer& buffer) override;

// Component CPP:
void Component::bufferPort_dropHandler(NATIVE_INT_TYPE index, Fw::Buffer& buffer) {
   this->deallocatePort_out(0, buffer);
}

In this example, a buffer that is dropped can be cleaned-up.

Drawbacks

The primary drawback of this solution is more autocoded handlers. Additionally, users would still need to be aware and handle these cases.

[bocchino]

This seems like a good idea. However, if we do this, I suggest adding a new queue full behavior such as handler or sync (i.e., the port gets converted to a sync port on queue overflow).

• If we handle the input in an alternate way, then arguably it's no longer a drop.
• The overflow handler is potentially dangerous, because it converts an async port to a sync port. For example, it can introduce deadlock. Potentially dangerous behavior like this should be called out in the model.

This is related to the issue that we should not have "passive" components with threads inside them. See nasa/fpp#261.

[LeStarch]

I like this! Then we can call out specific usage notes. e.g.

handler: on queue full, a handler is called to allow users to take action (deallocate a resource, emit an event, etc). However, users should be warned that this handler runs synchronously and as such these actions must be limited in scope. Deadlocks and other thread contention issues must be accounted for.