Our strategy of leaking the Stack to ensure safety is only effective if
the lifetime of the underlying stack memory is controlled by the
destructor of the Stack. We don't add this bound to unsafe_new, so that
users who wish to provide the necessary guarantees themselves can do so.
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