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
Afficher les réponses par date
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.
-
James Long -
Jeff Read -
Taylor R Campbell