Am Fri, 06 Nov 2020 17:48:26 +0100 schrieb [email protected]: > > 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.
