On hosted platforms, libstd allows safely borrowing values from TLS with
'thread lifetime and without a Sync bound. As a result, we can't
guarantee that sending a generator across threads won't create dangling
references or data races. In freestanding environments, the notion of
thread-safety is likely to be defined by the consumer of libfringe,
so our Send bounds and implementation are unlikely to be meaningful
anyway.
The use case is as follows: let's say I have a scheduler that uses
libfringe for context switching. A single thread may open several
sockets, each of which presents a std::io::Read interface, and
waiting in Read::read requires having a reference to the yielder
inside the socket.
This could be worked around with RefCell in the API consumer, but
there is no real reason to not implement it in libfringe.
close#48
This makes more sense, because "generate" implies *running*
a generator, not *returning* from a generator. That name was
a vestige of the time when libfringe only really provided a .next()
implementation, which made marginally more sense together with
.generate(), but it doesn't anymore when we have .resume().
edef
whitequark
Amanieu d'Antras