re: #231 (review)
Out of curiosity, any reason ProcessId is uintptr_t rather than HANDLE on Windows? Would remove the reinterpret_casts
Good question, I think you are right it could be good to use HANDLE instead. Probably original motivation for using uintptr_t was to avoid needing to pull in win32 headers for all code using mp/util.h, but maybe that bridge has already been crossed with inclusion of winsock2.h as per your other comment #231 (comment), so this should be revisited. Could also go the other direction and drop winsock2.h since it looks like it is only needed for INVALID_SOCKET definition.
Another potentially confusing about this is that process handles and process ids (as returned by functions like GetCurrentProcessId) are actually different things on windows. Handles are more useful for controlling and waiting for processes, but process ids are more globally unique and useful in other contexts.
Will look into alternatives here and try to add a clarifying comment at least.