RTEMS | cpukit/libio: Support close with IOP references held (!516)

Chris Johns (@chris) gitlab at rtems.org
Mon Jun 23 00:47:16 UTC 2025




Chris Johns commented on a discussion on cpukit/include/rtems/libio_.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/516#note_125070

 > +/**
 > + * This routine frees the resources associated with an IOP (file
 > + * descriptor) and clears the slot in the IOP Table. No checks are
 > + * made on the state of the IOP.
 > + */
 > +void rtems_libio_free_iop(
 > +  rtems_libio_t *iop
 > +);
 > +
 > +/**
 > + * This routine frees the resources associated with an IOP (file
 > + * descriptor) and clears the slot in the IOP Table. The IOP has to
 > + * close (open flag not set) and no references held or the call will
 > + * ignore the request.
 > + */
 > +static inline void rtems_libio_free(

Correct. We are currently wedged. The resource is reference counted so normally we would only ever free in a drop however the reference counting implementation is not clean because the open bit is a reference that is not reflected in the reference count and this effects real efficiencies we could get.

Take a look in `shm_open()` as an example of the explicit resource handling coded in opens. Ideally the allocate should have added one to the reference count and then free locations should be drops.

I have avoided taking that extra step in this change.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/516#note_125070
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20250623/b3fd14be/attachment.htm>


More information about the bugs mailing list