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