From: Lorien Dunn <loriend@...>
Date: 2002-09-13T19:05:13+09:00
Subject: Why can't ruby be used from a (native) thread other than the main one?

Hello,
	Yesterday I was assisting in writing the server for a multiplayer gladiatorial combat game that embeds ruby. This server has an MFC gui that spawns a single hi-priority thread that runs all our game logic (this is what we are doing with ruby). However when ruby is initialised from the child thread and only used from that child thread it segfaults strait away. As soon as the ruby initialisation and code was moved back to the main thread it worked.
	Has anyone found a way to work around this? We were using ruby-1.6.6 built with MSVC6 service pack 5. I will try with 1.6.7 on monday. I have not tried this sort of thing on linux.
	Our attempt to work around it involved making the game logic run in a separate process, started with IO#popen, and communicate between the two processes using pipes, however IO#getc and other similar methods are blocking instead of returning nil when there is no data in the pipe, and select() with a timeout of 0 is doing exactly the same thing (i.e. blocking). I guess this is a "feature" of the unix-emulation used by the msvc port of ruby. I'm thinking of getting the FILE*'s out of the IO instance, and polling them (from c++) with a native thread. But this is rather messy, and a cleaner solution would be nice.
	Also I'd like to add my voice to the request to be able to shutdown and re-initialise the ruby interpreter from c/c++.

Thanks,
Lorien Dunn