Thank you for the reply Xiang and bringing the PRs to my attention. If I understand the PRs, they don't quite satisfy my concern. In my use case, an application is killed while blocked on a call to poll(). This results in a call (initiated by the kernel) to the driver's close callback (which is as expected). But why doesn't the kernel call the driver's poll callback first (before close), to do the teardown of the fds? This would result in the proper cleanup in the driver without requiring changes to any existing drivers.
Regards Kian ________________________________ From: Xiang Xiao <xiaoxiang781...@gmail.com> Sent: 11 February 2025 06:53 To: dev@nuttx.apache.org <dev@nuttx.apache.org> Subject: Re: Driver poll question On Tue, Feb 11, 2025 at 2:00 AM Kian Karas (KK) <k...@thrane.eu> wrote: > Hi community > > I have a question related to the implementation of poll() in the kernel > and drivers. I am implementing a driver with poll support (through > file_operations::poll) and have observed that "teardown" of the pollfds is > not performed if the task is killed (while task is blocked on a call to > poll()). Is this intended behavior? > > it's impossible to recover reliably before file reference count( https://github.com/apache/nuttx/pull/13296) is implemented. > As file_operations::close is called it seems possible to find and remove > the FD, but I cannot find any driver doing that. This patch was merged recently, that's why you can't find the driver handle close with active poll spreadly. > Since close is actually called on the driver, I would assume the intention > is to clean up the driver, but I find it a little inconsistent that > cleaning up the pollfds does not happen. > > Yes, https://github.com/apache/nuttx/pull/15809 is an example demo on how to handle close with the active poll correctly. > I am using the "flat" build configuration. The beavior may be different in > "protected" builds? > > Regards > Kian >
