Windows: support DuplicateHandle on GetCurrentThread handle (and generally fix thread handle behavior)

[RalfJung]

The tests/fail-dep/concurrency/windows_join_main.rs test currently has to do hackery to obtain a handle for the main thread that is usable from another thread. The proper way to do that is to call GetCurrentThread to get a pseudo handle, then call DuplicateHandle to turn that into a "real" handle.

What's not clear to me currently is if that handle is identical to the kind of handle that is returned when spawning a thread. Those handles have the special property that closing them detaches the thread -- it would seem odd to do that when just closing a handle one got from DuplicateHandle?

Cc @beepster4096 @CraftSpider

[ChrisDenton]

Windows itself doesn't really have the concept of detached threads. Either you have a handle to a thread or you don't.

[RalfJung]

Ah... well then the current implementation we have makes little sense.

[beepster4096]

Hm. I wonder if the right approach might be to replace the entire handle scheme to be more like windows's own. Instead of storing handle data inline, store an id (or a pseudohandle kind) that points into a table. Maybe we can avoid duplication with the file descriptor table as well by storing Box<dyn FileDescription>s directly in the handle table.

[beepster4096]

Oh it looks like miri no longer stores files as Box<dyn FileDescription>, so it might be a little more complicated than that 😅

[RalfJung]

We store them as basically Rc<dyn FileDescription>.