<div dir="ltr">Hi<div><br></div><div>Starting another thread so we can focus on this without all the code in the way.</div><div><br></div><div>Chris' concern was that deleting the regulator includes deleting the delivery thread and that could cause the delivery function to leave resources like mutexes in an unknown state. He asked about a coordinated shutdown/delete.</div><div><br></div><div>In thinking about this, I realized that you cannot delete a partition while buffers it has given to a user are outstanding. It returns RTEMS_RESOURCE_IN_USE. This means the rtems_partition_delete() call will fail in Chris' scenario because 1+ buffers would still be outstanding.</div><div><br></div><div>My thought is to not allow the user to delete a regulator instance unless all buffers are released (e.g. in the pool). The buffers are logically in one of four states: in the unused pool, held by Source, pending delivery, or in the process of being delivered.</div><div><br></div><div>The application will have to perform some coordination to ensure all buffers are back in the pool. The source needs to quit producing and all messages pending delivery need to either be delivered or flushed. I'm proposing the following:<br></div><div><br></div><div>+ cannot delete unless all buffers are in the unused pool (e.g. none "obtained")<br></div><div>  - none need to be released</div><div>+ add method to flush messages pending delivery<br></div><div>+ add info method with number of buffers outstanding (e.g obtained but not released)<br></div><div>   - later maybe add more statistics.</div><div><br></div><div>The application would have to coordinate the clearing of the regulator by:<br><br>(1) stopping the Source from obtaining buffers and sending to the regulator</div><div>(2) flush the pending undelivered message OR wait for them to be delivered</div><div>(3) wait for there to be no outstanding messages</div><div><br></div><div>Then it could be deleted.</div><div><br></div><div>I considered adding a way to have the regulator stop accepting input and stop delivering but that does not address the issue of getting the buffers back which the Source may have. When the current message being delivered finishes, the buffer will be released. Ultimately, the application has to stop producing input and clear the "work queue" somehow. I think I have defined a fairly straightforward way to do that.</div><div><br></div><div>How does this sound?</div><div><br></div><div>--joel</div></div>