I figured it out. The poll() implementation already supports this (see poll_cleanup()), but it was (implicit) disabled in my configuration: CONFIG_TLS_NCLEANUP=0
Increasing it, solved the issue. The driver's poll "teardown" is then called before the driver's close function. Thank you for your input Xiang. Regards Kian ________________________________ From: Xiang Xiao <xiaoxiang781...@gmail.com> Sent: 12 February 2025 02:56 To: dev@nuttx.apache.org <dev@nuttx.apache.org> Subject: Re: Driver poll question How does the kernel know the killed thread is blocking in the driver's poll method? Adding some flag in tcb_s for the special usage mayn't good. BTW, there are many APIs that may block(e.g. write/read/send/recv), these methods do not public callback to cancel the internal wait. On Wed, Feb 12, 2025 at 4:10 AM Kian Karas (KK) <k...@thrane.eu> wrote: > 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 > > >
