[Libwebsockets] close adopted file from the user side

andy at warmcat.com andy at warmcat.com
Thu Aug 6 01:25:30 CEST 2020



On August 5, 2020 11:11:57 PM UTC, Per Bothner <per at bothner.com> wrote:
>I'm trying to cleanly close a file/lws created using
>lws_adopt_descriptor_vhost.
>
>In "Closing connections from the user side"
>https://libwebsockets.org/lws-api-doc-master/html/md_READMEs_README_8coding.html#closing
>it says this should be done by having the callback return -1, and
>you can force a callback using lws_callback_on_writable.

You can also close wsi synchronously or asynchronously

https://libwebsockets.org/git/libwebsockets/tree/include/libwebsockets/lws-timeout-timer.h#n77-101

>Does this apply also for "adopted" file descriptors?

Yes... it handles the wsi close and any descriptor close via the role it was bound to.  So closing the wsi will clean up any related descriptor.

>What if it's a read-only file?  Calling lws_callback_on_writable
>doesn't seem to force a callback in this case.

Yes you can use the timeout based close method above, it has been around for several versions.

>I can close this file descriptor, but doesn't seem to force a callback
>either:
>There is no LWS_CALLBACK_RAW_CLOSE_FILE call.
>(There is a LWS_CALLBACK_RAW_CLOSE_FILE call for a Unix domain socket,
>but not for an alias for stdin passed across over the socket.)

No the wsi owns the descriptor and has responsibility for closing it, you can't close the fd randomly same as you can't close a socket descriptor assigned to a live wsi randomly.  The wsi close flow will do it.

Closing the descriptor handle deallocates libc / os stuff related to it, if the wsi doesn't know you did it, it will try to close it a second time at wsi destruction, depending on the os / libc that will blow up.  So just let the wsi own it and close the wsi to close the descriptor.

-Andy


More information about the Libwebsockets mailing list