If you ever want to allow parking a fiber with a native method on the stack

[Stephane Epardaud]

TLS meaning thread-local storage, right?

It's possible to still support TLS on those special stacks, via an
indirection. It'd be more expensive.

As for the GNU/Linux limitation, I don't think it's a problem because in
the worst case you can dedicate a special thread for that reentering
native computation. And pool them. Remember they have to be explicitly
marked so you only pay the price of sync when you are sure to be
reentering. And again I assume it's rare enough. And also again, that's
all assuming it'd even be useful in the first place to support this.


On 13/08/18 22:08, Florian Weimer wrote:
> * Stephane Epardaud:
>
>> I've done this before in a Scheme VM that ran fibers-like threads. The
>> trick was to mark native methods that are reentrant (call back into
>> non-native code) so that they get executed in an alternate stack when
>> called by a fiber. The fiber would then wait for the native method to
>> either return or reenter and continue from there, in both cases with its
>> own stack clean. If that native call reentered you can mark the fiber
>> stack to remember it, and proceed. When you copy the fiber stack you
>> will copy the markers too and leave the delegate native stacks alone.
>> And when the fiber needs to pop back to the reentring native call you do
>> the same dance in reverse.
> That was before wide use of TLS, right?
>
> On GNU/Linux, you can only resume such a native computation on the
> same thread on which it was suspend, so this approach has limited
> applicability there.