CTRL+C doesn't quit the process properly anymore using a blocking socket

[Daddi]

Hi guys,
I'm using SFMLs network library to send simple data packets to a single client. That part works flawlessly.

When my program starts it initializes and in the end waits for a client using TCPListener.accept() with a blocking socket. When I want to close the program (console application) via CTLR+C "something" happens (e.g. OpenCV closes the connection to the webcam etc.) but the process itself doesn't quit. I have to terminate it via task manager.

If I comment the listening part out the program stops at the end of the main function as planned, so it should be a problem with the blocking socket.

What I tried is setting the socket unblocking and polling every 50ms in a while loop using sf::sleep(). But that also prevents the process to quit completely. I'd be okay using a keypress inside the while to break the loop and let the program run to the end of main, but I don't know how, as there is no window to get any events / key presses and I didn't find a way to do non-blocking console I/O via C++.

Edit:
Additional information:

Windows 8.1
SFML 2.2
Visual Studio 2013
Other used libraries: OpenCV, ArUco (AR marker tracking)

I start the process via the windows console command window.

[eXpl0it3r]

Which OS?

[Daddi]

Sorry, forgot the important things

Windows 8.1
SFML 2.2
Visual Studio 2013
Other used libraries: OpenCV, ArUco (AR marker tracking)

I start the process via the windows console command window.

[eXpl0it3r]

I've no idea what the requirements are for the SIGINT (or signals in general), but for me it seems a bit presumptuous to assume that any application will shutdown gracefully when sending the SIGINT signal while not actually handling any signals.

Signals are a basic OS feature and if one wants to use them with a certain purpose, one might as well handle them (see the MSDN).

As for the whole blocking part, you might want to read this thread and binary1248's points.

[Daddi]

I know about signals and already tried using a custom signal handler. It gets fired and prints a message, but even the following hard exit(1); does not stop the process.

The thread you mentioned did I read before I opened the thread, but I don't really get in which way this will help me with my problem? As I stated in the first post, I already tried using a non-blocking architecture.

[eXpl0it3r]

Guess it's time to get your debugger and find out where your thread hangs.

[Daddi]

After some more debugging I found out, that OpenCVs video grabber blocks the process somehow. If I don't initialize the camera, everything works as intended (the TCPListener is not to blame). Thanks for your help

If anybody reads my comment from above and looks for a way to do "unblocking I/O" in C++:
You can use the function kbhit() to get a boolean if any character was hit on the keyboard. May come in handy if you need to break an infinite loop without having a window open (no events / keyboard available).