Questions about QCon'19 London talk

[Volkan Yazıcı]

Thanks for the reply Ron.
My comments are inline.

On Thu, Dec 5, 2019 at 5:17 PM Ron Pressler <ron.pressler at oracle.com> wrote:
> On 5 December 2019 at 12:06:47, Volkan Yazıcı (volkan.yazici at gmail.com(mailto:volkan.yazici at gmail.com)) wrote:
> > *1.* In the talk, Ron states that the team considers implementing
> > Serializable in Continuation class. There it is further shared that the
> > continuation might even get resumed on a different physical machine than
> > the one it was suspended from. Given a majority of the continuation-related
> > marketing pitches are surrounded around I/O, how do you plan to preserve
> > the stateful nature of the I/O resources (e.g., a network socket) while
> > migrating a continuation bound to that resource from one machine to another?
>
> That will be up to application code — just as with serialization today.

If that is the case, I would rather not share that as an example. When
you speak of "database"s, people generally tend to think of RDBMSes,
where transactions are connection-bound. Putting exotic commercial
database features aside, many RDBMSes do not provide any support for
hijacking a transaction from a connection other than the one it was
originated from. (Please correct me if I am wrong.) I see your
intention to inform the audience of possibilities. That said, I would
rather exemplify a case involving no I/O, e.g, re-spawning a
generator.

> > *2.* In the structured concurrency example, that is, anyOf() method, why
> > don't we just replace the entire "try { } catch (...) {
> > ... } finally { }" with just ""?
> > Isn't the purpose of "" already served by
> > try-with-resources on FiberScope?
>
> Well, for one, the entire structured concurrency API is very much in flux,
> so much so that it doesn’t exist in the current prototype at all. But in the
> API presented, the implicit call to close() in the TWR block waits for the
> completion of all threads; it does not attempt to cancel them.

Hrm... That is totally contrary to my impression from a TWR on a
"cancellable" fiber scope. I was expecting all fibers within a
"cancellable" scope of TWR to get "cancelled" on either graceful or
premature exit. Apparently, I am mistaken. Maybe it is just me, but I
personally found it counter-intuitive. For instance, I can imagine TWR
on a regular FiberScope to wait for termination of all fibers, or TWR
on a "time-limited" FiberScope to wait for the timeout, etc. But the
impression generated by the API for "cancellable", IMHO, is not
aligned with these.

I also find it always puzzling to see a try/catch within a TWR. It
sort of feels like defeating the purpose of TWR -- which might not
necessarily be the correct.