> Don't most Scheme only implement green threads?  Only Chez did system
> threads long ago (with shared memory, I should add), but some more have
> implemented them as of late.  Given that switching system threads is
> expensive, I'd expect many of these to run their own code in user
> threads as needed.

Cyclone is one new R7RS implementation using native threads.
<http://justinethier.github.io/cyclone/>

More generally, SRFI 170 will hopefully be useful for at least two
decades. Who knows what threading strategies Scheme implementations (and
the underlying operating systems) will deploy in that time?

>> I too am beginning to think that there is no natural client for SRFI
>> 199.  If you want to fake a Posix error, SRFI 198 will allow that, but
>> I think picking up the actual value of errno has to be done (very
>> carefully) in C, where only Posix threads matter.

+1, thanks for listening.

> Doesn't SRFI 198 still need *an* API to get errno from, even if it's not
> this one?  There's also a general need in POSIX interfacing to set errno
> before using some system or library calls.  I created SRFI 199 because
> you don't believe that API should live in SRFI 198.

The Scheme side should get the errno value from the FFI glue procedure
of each particular syscall. Anything else is error-prone (no pun intended).

"Set errno to zero before calling a syscall" is an anti-pattern in
syscall design and there should only be a few syscalls in existence that
need it. The errno-setting-and-getting should be rolled into the FFI
glue. IMO, nothing good can come from exposing Unix to Scheme at this
level of granularity :-) It is "unwarranted chumminess with the
[operating system]", to steal a phrase from Dennis Ritchie.