[gambit-list] callbacks and threads -- can we deduce the root cause from this cure

[Jörg F. Wittenberger]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gabit-foreign.scm
Type: text/x-scheme
Size: 3673 bytes
Desc: not available
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20200506/080439b5/attachment.bin>