Crash when using `ovos-speak`

[goldyfruit]

$ ovos-speak "Hello world"
2023-06-08 11:34:57.386 - OVOS - ovos_bus_client.session:reset_default_session:225 - INFO - New Default Session Start: d64a1ad3-8ae6-4a08-a160-afaf39e1aa03

Connection opened.
There are now 18 open connections.
[2023-06-08 11:34:57] [connect] WebSocket Connection [::ffff:127.0.0.1]:44224 v13 "" /core 101
[2023-06-08 11:34:57] [control] Control frame received with opcode 8
message handler on the main thread
Message payload:
{"context":{"session":{"active_skills":[],"context":{"frame_stack":[],"timeout":101174309760},"history":[[{"context":{},"data":{"lang":"fr-fr","utterance":"Hello world"},"type":"speak"},1686238497.3873408]],"lang":"fr-fr","session_id":"d64a1ad3-8ae6-4a08-a160-afaf39e1aa03","utterance_states":{},"valid_languages":["fr-fr"]}},"data":{"lang":"fr-fr","utterance":"Hello world"},"type":"speak"}
[2023-06-08 11:34:57] [frame_header] Dispatching write containing 1 message(s) containing 2 header bytes and 2 payload bytes
[2023-06-08 11:34:57] [frame_header] Header Bytes: 
[0] (2) 88 02 

[2023-06-08 11:34:57] [frame_payload] Payload Bytes: 
[0] (2) [8] 03 E8 

terminate called after throwing an instance of 'websocketpp::exception'
  what():  invalid state
Aborted

[JarbasAl]

this happens when the connection is closed too fast i think, will happen in all the cli apps that emit a bus message and immediately exit

same as https://github.com/OpenVoiceOS/ovos-bus-server/issues/3

[goldyfruit]

this happens when the connection is closed too fast i think, will happen in all the cli apps that emit a bus message and immediately exit

same as #3

Indeed, the server crashes because the thread is closed too quickly; cf: https://stackoverflow.com/questions/7381757/c-terminate-called-without-an-active-exception

Adding a sleep time.sleep(0.2) before the client.close() prevent the server to crash. https://github.com/OpenVoiceOS/ovos-bus-client/blob/dev/ovos_bus_client/scripts.py

[ChanceNCounter]

quoting self in chat:

well, it boils down (as that StackOverflow link explains) to what the C++ standard has applications do for thread safety. what's going on here is, your dep is still in the process of joining the thread created by the connecting client when the client disconnects. disconnecting puts the handler out of scope before it's joined. the program crashes rather than leaving detached threads

options: become more involved in all the threading this server is doing. introduce that hardcoded sleep to the clients. rewrite this in golang.