I need the ability to create OS threads because of the blocking nature of the c calls (mainly with c functions that do network stuff). I ended up wrapping up boost's excellent thread library in c functions (everything is compiled as c++ now because it's a c++ library, which should be fine) to maintain cross-platform-ness. The resulting interface is clean and simple and it works great.
I noticed what should have been an expected result, however, and I'm interested in exactly what's going on. When I call a scheme function from my created OS thread, the process crashes if it does anything with I/O or anything more complex than an if/then statement. My example app crashed when I tried to call 'display' from the OS thread.
I know that we are entering Scheme totally outside of it's threading system, which means it's probably accessing memory that it normally wouldn't be allowed to. Is it just a result of Gambit using shared memory often, so two executions of Gambit code corrupt each other? Again, I'll usually use the OS threads to only call C code so this isn't a problem, but I was just curious about the internal workings of Gambit (and possibly if it will support OS threads in the future? or is that Termite?)
James
James,
On 2/25/07, James Long longster@gmail.com wrote:
I need the ability to create OS threads because of the blocking nature of the c calls (mainly with c functions that do network stuff). I ended up wrapping up boost's excellent thread library in c functions (everything is compiled as c++ now because it's a c++ library, which should be fine) to maintain cross-platform-ness. The resulting interface is clean and simple and it works great.
Have you considered nonblocking I/O? I do not know enough about your application to know whether this is practical or not (some network operations like DNS can't easily be made nonblocking), but it is the approach I have taken for Gamsock, for better cooperation with Gambit's (non-native) thread system.
By the way, new Gamsock at: http://www.parodycheck.net/software/gamsock.tar.gz or darcs get http://www.parodycheck.net/repos/gamsock
--Jeff
Date: Sun, 25 Feb 2007 03:11:40 -0500 From: "James Long" longster@gmail.com
I need the ability to create OS threads because of the blocking nature of the c calls (mainly with c functions that do network stuff).
One way to get around this is to serialize the communication between the Scheme OS thread and the other OS threads through a pipe, on which there can be non-blocking I/O. I implemented a proof of concept for Scheme48 at http:///mumble.net/~campbell/tmp/s48-addrinfo.tar.gz; perhaps you can scrounge some code or at least ideas from there.
On the Scheme side, Scheme threads call out to the C request code and enqueue a `placeholder' to be set when a response is returned; a placeholder is a write-once cell on which readers block until it is written to. The C request code sends a request by pipe (or any other mechanism, really, although we use a pipe here) to a different OS thread and returns a pointer to where the result will be stored. The Scheme threads then wait.
There is one dedicated Scheme thread that reads from a pipe, which the separate OS threads will write to in order to indicate a response; that Scheme thread distributes the responses to the appropriate Scheme threads that were waiting for them.