Re: Some questions about concurrency (mostly)

[Jörg F. Wittenberger]

Am Fri, 06 Nov 2020 17:48:26 +0100
schrieb felix.winkelmann@bevuta.com:

> > I'm not doing any call/cc or non-local exit shenanigans, but the
> > code uses srfi-18 threads and does I/O over TCP. As I understand
> > it, srfi-18 is implemented using continuations. Will that cause
> > problems with my with-lock function? I'm thinking that a thread
> > that has aquired the lock in the before-thunk and running the main
> > thunk might hang waiting for I/O; will that cause it to exit the
> > dynamic environment, run the after-thunk and release the lock?  
> 
> Each thread has its own dynamic-wind chain, so unless you start
> threads in the before/after threads, you should be fine.

As I wrote before: beware of subtile interference between a) srfi-18
and exception handling regarding the `abandoned` state of the mutex or
even better b) srfi-154's idea of a `current-dynamic-extent`.

Both are great ways to create showcases how to confuse code, which calls
mutex-(un)lock! from within `dynamic-wind`-installed handlers.

I'd LOVE to be able to tag procedures to be "dynamic-wind-safe" to the
extent that calling them from such a context raises an exception!

Having though more in the past hours about this - actually frequently
recurring issue, which I, admittedly got personally wrong for several
years - I'd even take back my recommendation to EVER call
`mutex-unlock!` from unwind-handlers.  Just figure out in the handler
whether or not to handle the exception and defer `mutex-unlock!` until
after the exception handler completed (or don't call it if the handler
re-raises the exception).

This topic is labeled: "dragons ahead" for me.

Just consider `mutex-`* operations NOT safe to be called from
`dynamic-wind` "before" and "after" thunks.