From: Jari Williamsson Date: 2008-01-25T18:29:00+09:00 Subject: Re: Using a DLL that wants a function pointer daniel �kerud wrote: > On Jan 24, 2008 10:11 PM, Daniel Berger wrote: > >> On Jan 24, 1:52pm, "daniel �kerud" wrote: >> >> >> >>> I think this is important in this context: The callback is called from >>> another thread, i.e. the DLL creates a thread that reads data in the >>> background, and when data arrives it calls the callback. Would this be a >>> problem if the Ruby extension calls the Proc object from another thread, >> and >>> if so, how to solve it... >> At the moment, you don't. Windows callbacks occur in their own native >> thread. The Ruby interpreter isn't thread safe. You'll get one >> callback call to work, but after that it will probably segfault. >> >> Heesob is working on this for the C side of the house to see if he can >> come up with a way to make it work. In the meantime, I'm going to see >> if I can get win32-api ported to JRuby using JNA this weekend. That >> *should* work, though it means you'll have to use JRuby to use it, >> which may not be such a bad thing. :) >> >> Regards, >> >> Dan >> >> > What if I provide a polling-mechanism, i.e. the Ruby-extension puts all data > from the callback in a queue, and the Ruby-script poll()s periodically to > see if there is any data. In this case, to Ruby, everything will happen in > the same thread. Indeed this removes the callback interface Ruby-Script -> > Ruby-Extension (which indeed is the subject...), but it circumvents the > threading-problem. Would it work? Yes, that would work if you make the data queue thread safe, probably using a Windows mutex (and wait with no timeout duration in the Ruby thread). Best regards, Jari Williamsson