The following threads wouldn't die: ['httpd@8080_1']

This error message was posted in another topic about trying to find the error message in the code.

% The following threads wouldn't die: ['httpd@8080_1']

To which Jan W. replied:

The actual cause is hinted at with halt/1: threads are aborted and joined, but those not responding within a second are forcefully cancelled. Typically is because they are running foreign code that does not do signal processing.

The associated replies were then moved to this topic.

Personal notes (Click triangle to expand)

Test cases and such written by Jan W. are often some of the best example code of how combinations of predicates work together. For understainding the predicates used with threads for SWI-Prolog one of the best examples is this:

https://github.com/SWI-Prolog/packages-clib/blob/master/stresssocket.pl

@jan - Should any well-behaved server call http_stop_server/2 before it exits? The http_daemon/0 [demo_daemon.pl](http://demo_daemon.pl) doesn’t, but is that an oversight?

Normally all is aborted and that works fine. No clue why it didn’t here.

The code that orignally resulted in the message was part of an http server that uses web sockets.
The code is still being developed and how the message was found was that protocool/1 was used to capture the console output, including messages after halt/0 was called at the top level.

After posting the topic modified the code to close down the open web sockets initiated from the server in at_halt/1 using ws_send(WebSocket,close(1001,"Bye")) then http_stop_server/2 is called but I am not sure if that is correct but it does work.

So, “normal” shutdown will kill any queries that are being processed but http_stop_server/2 will wait until they’re finished? If a query is killed (“aborted”), does any indication get sent back to the client, or does it just time out or get a “connection closed” on the socket?

I think it gets an “internal server error” page from handling the exception. Else it surely gets a lost connection.

But yes, probably it is more elegant to schedule a stop server using at_halt/1. Probably that needs a timeout though.