Feedback on the API

[Volkan Yazıcı]

Hello,

Even though the current prototype interfaces are not finalized yet, I would
like to share some feedback in no particular order.

   - Fiber.schedule() ergonomics is not aligned with Executor#invoke*() and
   Executor#submit().
   - Maybe it is just me, but I anticipate people will try to reach out for
   the fiber counterpart of Thread.sleep(). (I am very well aware of
   Thread.sleep() does not block the fiber scheduler thread.)
   - Propagating InterruptedExceptions via
   Thread.currentThread().interrupt() is a pretty common practice. That said,
   typing Thread.currentThread().interrupt() in a fiber body feels like I am
   doing something wrong.
   - FiberScope interface feels like a black box. Is it supposed to be
   extended? Am I constrained to the default provided ones? What does a
   FiberScope technically deliver? It is not really intention revealing.
   - Please don't pollute FiberScope with static accessors of particular
   implementations, e.g., FiberScope.currentDeadline(). FiberScope.current()
   would be good enough. Then each implementation can introduce their own
   accessors.
   - Isn't there a garbage-free way to access the result of a Fiber? Do we
   always need to convert it into a Future?
   - It would be handy if users could pass their own BlockingQueue
   implementations to FiberScopeImpl. (This is a pain point in
   ScheduledThreadPoolExecutor, IMHO.)
   - In its current form, FiberScope needs to be explicitly passed to
   Fiber.schedule(). If you schedule a fiber within a scope and that fiber
   directly or indirectly schedules a new fiber discarding the scope in use,
   your beautiful scope serves no purpose anymore. And I think this leakage of
   fibers totally contradicts with the goal of structured concurrency. I can
   understand fixing this incurs a well thought new concept, e.g., special-,
   FiberScoped-, TaskLocal-, etc. variables. Though unless one can implicitly
   employ the active scope for the upcoming fiber schedulings, FiberScope is
   no better than hand crafted deadline facilities, which I believe what we
   are trying to avoid.
   - While "scope" term in FiberScope makes perfect sense, I find
   "ContinuationScope" confusing. It rather feels like a "state" than a
   "scope".
   - I find it surprising that I explicitly need to pass a
   ContinuationScope to the Continuation ctor. As a programmer, I am only
   interested in wrapping my Runnable within a Continuation and I do not much
   care about the ContinuationScope. Further, ContinuationScope provides
   nothing more than what an Object has -- except ContinuationScope#getName().
   Why is it exposed in the interface at all?

Best.