Windows API - GetLastError woes

[Simon Marlow]

Esa Ilari Vuokko wrote:

> My "use case" is in Win32-package, where we simply call a FFI
> imported call and on failures call GetLastError to get extended
> error code.  GetLastError of course only works on same OS thread
> and contains sensible results only before next Windows API call.
> It's much like C/posix errno.
> 
> So, we *must* call GetLastError in the same OS thread, and there
> must not be any Windows API calls in between, including those caused
> by, say, rts' memory allocation or calls to lock mutexes.  Unless the
> error code is saved via Get/SetLastError.
> 
> Also, I'd like not to run the code in a another OS thread (and
> that won't fix the rts-caused Windows API calls), because the calls
> are supposed to be fast, and OS-level context switch isn't fast.
> 
> Is this problem real, or did I miss some magic feature of rts?

This is most definitely a real problem.  On Unix we have some hacks to make 
errno thread-local: basically we store it in the thread state object for the 
Haskell thread, and make sure we save/restore it around any RTS operations that 
might affect it.

We need to do the same tricks on Windows using GetLastError/SetLastError, it 
shouldn't be too difficult.  Would you like to submit a ticket?

Cheers,
	Simon