Fix osproc so that it doesn't close pipe/process/thread handles twice

[demotomohiro]

I added error check code to closeHandle call used to implement osproc procedures for windows.
And I got invalid handle error because pipe handles and process/thread handles are closed twice when execCmdEx proc in osproc module is called.

This PR adds error check code to closeHandle, doesn't close handles twice and set INVALID_HANDLE_VALUE or 0 after the handle is closed so that finding handle use after close is easier.

According to this blog post, invalid handle value of a file handle and a process/thread handle is different.
https://devblogs.microsoft.com/oldnewthing/20040302-00/?p=40443

[juancarlospaco]

doAssert because is an important check, and add a descriptive error message to it IMHO.

[demotomohiro]

I don't think it should be doAssert.
As far as I know, these asserts fails only when close(p: Process) was called or outputStream/errorStream was closed before close(p: Process) is called.
These errors can be detected if assert was on.
If no asserts failed when assert was on, these error should never happen in -d:danger build.

[timotheecour]

these error should never happen in -d:danger build.

they could, because a different code path can be executed based on runtime conditions that would only be run in production. Generally, there's no point in skipping some assert if the cost of the check is dwarfed by the cost of the proc it lives in, which is the case here (the syscall would dwarf a simple check)

[alaviss]

If possible, please provide ways to close I/O handles from user code, as it is needed for some use cases (like execCmdEx) and is currently incorrectly done via closing the .inputHandle, which leaves the handle to be closed an another time with process.close().

[juancarlospaco]

If you gonna tweak a close() is not better to make a destructor ?. 🤔

[Araq]

If you gonna tweak a close() is not better to make a destructor ?.

That would be a refactoring, for another time where we patched the stdlib to use destructors... :-)

[planetis-m]

Thank you for fixing this :)

[demotomohiro]

If possible, please provide ways to close I/O handles from user code, as it is needed for some use cases (like execCmdEx) and is currently incorrectly done via closing the .inputHandle, which leaves the handle to be closed an another time with process.close().

In osproc's Posix code, it seems closing Stream before calling close(p: Process) is safe.
It checks nil before closing the file handle and sets nil to the file handle when stream is closed.
File handles of pipes are closed same way in close(p: Process).

This PR fix the problem in windows implementation in the same way and you can close input stream safely before closing process.
But closing output/error stream cause assertion fail because I don't think it doesn't need to be closed before closing process.
You need to close process.inHandle when you want to send end of file to child process. But is there any case you need to close outHandle or errHandle before the child process exit?

[timotheecour]

@demotomohiro pre-existing but where does this magic h > 4 comes from? shouldn't that at least be h > 2 ?

eg assuming stdin=0,stdout=1,stderr=2, what about files with fileno equal to 3 or 4 ?

at very least we need a comment explanining where this comes from