Hi guys,
Thank you for the new release 0.9.72. Does it solves the issue I
reported here? Not sure. I have not tested yet and I'm not sure to be
able to test it soon. Have you checked? I had no confirmation or
feedback since weeks...
Best regards
Happy new year
José
On Thu, 10 Dec 2020 16:08:18 +0100
José Bollo <jose.bo...@iot.bzh> wrote:
> Hello,
>
> My code uses LMHD embedded with its EPOLL mechanism. Part of that code
> deals with upgrading to websocket. It then call somewhere:
>
> response = MHD_create_response_for_upgrade(
> upgrade_to_websocket, memo);
>
> and the callback function upgrade_to_websocket looks as here below:
>
> void upgrade_to_websocket(
> void *cls,
> struct MHD_Connection *connection,
> void *con_cls,
> const char *extra_in,
> size_t extra_in_size,
> MHD_socket sock,
> struct MHD_UpgradeResponseHandle *urh
> ) {
> struct memo *memo = cls;
> struct ws *ws = ws_create(sock, memo, close_websocket, urh);
> if (ws == NULL) close_websocket(urh);
> }
>
> void close_websocket(struct MHD_UpgradeResponseHandle *urh) {
> MHD_upgrade_action (urh, MHD_UPGRADE_ACTION_CLOSE);
> }
>
> Thank you for your attention until here. So far, so good.
>
> The issue now: when the functiuon ws_create returns NULL, the program
> returns to some polling and wait for an events BUT DOES NOT CLOSE THE
> SOCKET, leading to starvation of the client.
>
> I guess that calling some function after calling MHD_upgrade_action
> (urh, MHD_UPGRADE_ACTION_CLOSE) could unlock the situation by
> performing correct close. Though the called function should not be
> MHD_run because it dispatch events, what is not expected here.
>
> I join a sample demo. When I connect on websocket on it, the client
> starves. I recorded and joined the output of strace.
>
> Best regards
> José Bollo
>
>
