Hi all,

these days spent endless hours trying to pin down the root cause of all sorts of breakage I encountered.

I'm afraid the manual section 19.7 hints somewhat towards it. How is the threading system actually implemented in gambit? Would a thread switch within a C-to-Scheme call originating from a Scheme-to-C count as an escape using first-clall continuations?

If so, how would I best protect against this? (Note: I'd like to _not_ loose the ability to call interpreted code from these callbacks.)

In my situation there are two third party C-libraries both calling back that way. Once one of them needs a mutex the other one holds the hell breaks loose.

Attached some code declaring a c-safe-lambda macro, which takes a supposed-to-gambit-global lock and a replacement for thread-start! to be used from within those callbacks. (This will delay the actual start of the thread until the c-safe-lambda has returned to Scheme.)

This appears to cure the issue. So far at least.

But I'm afraid it might be a red herring and just mitigate the effect for the hell to come back under more load.

To my surprise even starting a new thread from within such a callback appears to still beg for trouble. Even after being sure that there are no overlapping callbacks. I interpret this as a sign that the root cause might be something else.

Thanks for your comments.

/Jörg