Hello
For writing interfaces to C libraries which have socket function calls hard wired (like database client libraries), how can I make foreign calls so that they don't block other scheme threads?
At first, I've thought about hacking those libraries so that they allow the socket functions to be replaced by callbacks (to functions which go into the gambit scheduler / select loop), but then I realized that this won't solve the problem, since for each scheme thread that is calling a foreign function a separate C stack would be necessary, or there would be no way to let threads continue which don't have their C call frame at the top of the stack.
So the only solution seems to be using a separate pthread for each foreign function call done by a scheme thread. (The pthread could be cached and reused for subsequent foreign calls by the same scheme thread, or even be reused for different scheme threads after the scheme thread has finished.)
I don't know yet the details about how to set up the connection between those pthreads and the scheme calls. I guess by using some mutex which can be accessed by both scheme and C and passing the arguments through some thread-local storage. (I've read that the GHC Haskell compiler does something like this. I could take a more detailed look there.)
Has anyone done something like this already? Any hints, ideas, suggestions? (Would there be interest to include a solution into the Gambit distribution?)
Thanks Christian.
Afficher les réponses par date
* Christian christian@pflanze.mine.nu:
For writing interfaces to C libraries which have socket function calls hard wired (like database client libraries), how can I make foreign calls so that they don't block other scheme threads?
The libraries often have provisions for this. See for example PostgreSQL's client library and its PQconsumeInput, PQisBusy, etc. But I guess the C libraries you're using don't support this, then?
It could be that the best solution is to just implement the protocol in Scheme.