On 3/12/21 1:31 PM, Rémi Bernon wrote:
On 3/12/21 1:27 PM, Piotr Caban wrote:
Hi Rémi,
On 3/12/21 11:02 AM, Rémi Bernon wrote:
+static HANDLE msvcrt_input_console(void) {
+ HANDLE console; + LOCK_CONSOLE; + if (!MSVCRT_console_in) + { + MSVCRT_console_in = CreateFileA("CONIN$", GENERIC_WRITE|GENERIC_READ, + FILE_SHARE_WRITE|FILE_SHARE_READ, + NULL, OPEN_EXISTING, 0, NULL); + if (MSVCRT_console_in == INVALID_HANDLE_VALUE) + WARN("Input console handle initialization failed!\n"); + } + console = MSVCRT_console_in; + UNLOCK_CONSOLE; + return console; +}
I think that the caller should be responsible for locking. It's especially important for the _nolock functions that shouldn't lock at all.
Thanks, Piotr
Ah alright, so how should these be handled? We could also probably make the helper lockfree with interlocked exchange.
You can just remove the LOCK_CONSOLE/UNLOCK_CONSOLE from the msvcrt_input_console/msvcrt_output_console functions (it also makes the console handle not needed). In case of _nolock function the application is responsible for making sure the functions are called in thread-safe contexts.