Re: Some questions about concurrency (mostly)

[Chris Vine]

On Sat, 7 Nov 2020 20:02:12 -0500
John Cowan <cowan@ccil.org> wrote:
> On Sat, Nov 7, 2020 at 5:51 PM Chris Vine <vine35792468@gmail.com> wrote:
> >On Fri, 6 Nov 2020 17:20:04 +0100
> >"Jörg F. Wittenberger" <Joerg.Wittenberger@softeyes.net> wrote:
> > > This approach is bound to fail badly.
> > >
> > > It works just as long as there are a) no exceptions raised in `thunk`
> > > b) no code, not even in a library does any `call/cc`.  Including
> > > `call/cc` hidden in exception handlers (srfi-12, srfi-34 etc.)
> >
> > For my elucidation, why?  The indentation of the code isn't ideal but
> > the whole purpose of dynamic-wind is to handle code leaving the thunk in
> > case of exception, application of a continuation object or regular
> > return.
> 
> You're right about the second and third cases, but not the first.  Raising
> an exception *simply* calls the current exception handler, which is then
> free to return to the point of call like any other procedure.  In such a
> case, the after-thunk is not run, since dynamically you are still inside
> the main thunk.  This is a fundamental distinction between Lisp exceptions
> and every other language's exceptions.
> 
> Only if the exception handler uses call/cc to escape back to the dynamic
> context where the handler was set up is the after-thunk run.  This is done
> for you automatically if you use `handle-exceptions` or `chicken-case` or
> R7RS `guard`.
> 
> If you raise an exception with `abort` or `error`, then if the handler
> returns, another exception "unexpected return from handler" is raised.
> 
> Note also that when the thread scheduler switches to a new thread, any
> before- or after-thunks are not run, as the thread is supposed to be
> unaware that the switch happened.

Sure, thread context switches would be unusable if they triggered
dynamic winds.  A good job they don't.

Although there is little in it, I think I was right about the first
case.  If an exception does not result in the dynamic environment
of the raise being left, then this could only occur in the case of a
duly handled continuable exception, and in that case the exception
would not result, using my words, in "leaving the thunk"[1].  Instead,
all that would have happened is that the exception handler would have
executed in the thunk as if on a function application.

As it happens, that case is unusual: where for example the R7RS guard
and similar macros are involved the dynamic environment of the thunk
would be left in order to examine the relevant cond clauses, so the out
handler would be invoked, and for R7RS guard if no cond clause matches
it would invoke the in handler in order to re-raise the exception,
followed by the invocation of the out handler again after the re-raise
(unless the exception is continuable and is handled elsewhere on the
next attempt).  For such a case the proposed with-lock function would
be highly useful: it would guarantee the correct result whatever the
outcome.

I wonder therefore why you think that this renders the proposed
with-lock function inappropriate, if that is what you were implying?
Perhaps you weren't and were making some other point.  Macros for
handling resources such as mutex invoking dynamic-wind are commonplace.

[1] I am somewhat perplexed with your post because you seem to be
agreeing with me when disagreeing with me: you say that in the case
mentioned "dynamically you are still inside the main thunk".