win,libuv: support multiple threads

[vtjnash]

turns off the "do not work" flag

fix #32087

[vtjnash]

JuliaLang/libuv@2348256...26dbe56

[Keno]

As I commented on the relevant commit somewhere. I don't think this fix is sufficient in the presence of more threads than the number of cores in the machine. The problem is that threads retain their completion port association, but we migrate the completion port to a different thread. Ideally we'd have a way to drop that association and keep this value as is.

[JeffBezanson]

That makes sense, but in the meantime this is a much-needed improvement. It makes the difference between simple threaded code locking up every time vs. generally working.

[vtjnash]

That's something to consider in the future, although hopefully less of a concern, since any blocking call to the kernel should enable releasing a new thread from the IOCP. If we do continue with the current IO design unchanged, there is a way that this should be addressable per the MSDN documentation:

Although any number of threads can call GetQueuedCompletionStatus for a specified I/O completion port, when a specified thread calls GetQueuedCompletionStatus the first time, it becomes associated with the specified I/O completion port until one of three things occurs: The thread exits, specifies a different I/O completion port, or closes the I/O completion port. In other words, a single thread can be associated with, at most, one I/O completion port.

[Keno]

Can we just set that value to something like typemax? Are there any resources allocated proportional to that value? If not, setting it really high is probably a solution, since we can't allocate that many threads anyway.