Fibers and cygtls

Corinna Vinschen
Fri Sep 4 19:51:43 GMT 2020

On Sep  4 12:13, David McFarland via Cygwin-developers wrote:
> For a while now I've been trying to get nix working on Cygwin. It
> compiles fine, but when it's run, it will exit unexpectedly in a way
> that doesn't return an error code to Cygwin, and doesn't break in gdb.
> I tracked this to its use of boost coroutines, which use boost-context
> to switch fibers. boost-context can be built using either a custom asm
> implementation, or using windows fibers (CreateFiber).
> Both the boost-context asm implementation and win32 fibers switch the
> NT_TIB StackBase and StackLimit fields (to a user provided buffer) when
> switching fibers. StackBase is used to find the cygtls for the current
> thread (in _my_tls, and with asm in gendef etc). Because of this, A
> program will crash when any syscall is made from a fiber.

Using Windows fibers verbatim is rather dangerous in the Cygwin context.

There are more problems than just the tls area on the thread stack.  If
you call CreateFiber, you get an arbitrary stack created by Windows.
The x86_64 stacks are all in reproducible slots in the thread stack area
starting at 0x080000000L.  One very important reason is that standard
Windows stacks tend to break reproducability at fork() time.  As for
the i686 stacks... never mind, it's hopeless anyway.

There's something vaguely similar inside Cygwin, the implementation
of the alternate signal stack (sigaltstack).  For a comment on how
this works see the comment in, line 1726ff.  This may
(or may not) be a role model for implementing coroutine stacks.

Bottom line is, before trying to use Windows fibers, or before letting
boost use Windows functions on Cygwin (sigh), check what other POSIX or
BSD systems provide to implement coroutines.  If there's an API, let's
implement this API in Cygwin and then use that from user space.


More information about the Cygwin-developers mailing list