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.
<br><br>I noticed what should have been an expected result, however, and I&#39;m interested in exactly what&#39;s going on.&nbsp; 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.&nbsp; My example app crashed when I tried to call &#39;display&#39; from the OS thread.
<br><br>I know that we are entering Scheme totally outside of it&#39;s threading system, which means it&#39;s probably accessing memory that it normally wouldn&#39;t be allowed to.&nbsp; Is it just a result of Gambit using shared memory often, so two executions of Gambit code corrupt each other?&nbsp; Again, I&#39;ll usually use the OS threads to only call C code so this isn&#39;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?&nbsp; or is that Termite?)
<br><br>James<br>